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(S7) Abstract 

A method and system for modeling of objccn>ricntcd database sioicnifes. translation to relational database stnjcmres. and dynamic 
searches thereon. The user may create, edit and manipulate a user's object database (dynamically translated into a set of retoiional database 
structures) to create, edit and manipulate objccu for that object database (dynamically translated into dan for those relational datat»se 
strictures)* and to create, edit and manipulate queries to be applied to that object daoibase (dynamically translated imo quenes to be applied 
to those relational database stnicnires). A mcta-mode! of the user's object daubase. which is itself an object database, and which has nself 
been translated imo a set of relational database strucwres for manipulation by a relational database engine. The meta-modcl comprises a 
set of classes objects, and relalionships between classes which model the classes and relationships bcnween classes of the system. Each of 
these classes may comprise a set of searchable properties, and each of these rctotionships may comprise an inheritance relationship (between 
a base class and a derived ctoss) or a daia-model relationship (such as a one-io-one. one-to-many, or many-io-many relationship!. The data 
model of the user s object database is modeled by acnial objecu in the meia-model. and editing or manipulating the user s object database 
is modeled by creating, modifying, or deleting objects in the mew-model. The meia-model also models itself, in the same manner as ii 
models the user's object database, and may be manipulated in the same manner as the user's object database. 
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Title of the InventioD 

Modeling of Object-Oriented Database Structures, Translation to Relational Database Structures, 

and Dynamic Searches Thereon 

Background of the Invention 

L Field of the Inventton 

This invention relates to modeling of object-oriented database structures, transla- 
tion to relational database structures, and dynamic searches thereon. 

Z Description of Related Art 

In the design of computer software systems, it is considered superior to associate 
each data item with a data type, and to present a relatively uniform interface to objects of each data 
type to all elemoits of the system. This technique allows elements of the system to rely on the 
characteristics of the data type, of the unifonn interface to that data type, and of the relationships 
between that data type and other data types. In addition to so-called "built in** data types, such as 
integers and floating point numbers, it is also superior to extend this technique to more complex 
data types, sometimes called "classes," including classes defined by a user of the system. (For ex- 
ample, a user might define a class called telephone number and thus allow elements of the system 
to store, manipulate, or retrieve telephone numbers as if they were fundamental pieces of informa- 
tion.) Techniques of defining classes of software objects and restricting access to those objects are 
now common with some programming languages, such as the C-h- and Smalltalk programming 
languages, called object-oriented programming languages TOOPL'*). 

Recently it has been found that the technique of defining classes of software objects 
and manipulating those objects has been usefiil for database applications as well. In object-oriented 
database ("OODB") applications, a user defines classes of objects, properties of those classes, and 
relationships between those classes, and populates a database with data items which are instances of 

1 



wo 96/34350 



PCTAJS9M5678 



thoscobjects. (For example, the class ^]q>\mP vmfi?^ might be used to store telephone numbers 
for persons, companies, and computer networks.) It has been found ^t object-orioited database 
management presents the advantages of rs^id application and database develqmient and of relative 
software reliability. 

However, one problem whidi has arisen in die art is that many database systems 
have been designed to operate with another, diflFcrent database technique, known as "relational da- 
tabase" management (RDBM). In a relational database, the database comprises a set of data tables 
which represent the relationships between data items. Each table comprises a set of records, one 
record for each data item; each record comprises a set of columns or fields, one colunm for each 
data value associated with the data item. (For example, each record in a table of persons might 
have a column defined for that person's telejAone number, similarly, each record in a table of com- 
panies might have a column defined for that company's telephone number.) Relational databases 
have been found to be successfiil and efficient in managing large databases. Due to their success, 
there is a substantial investment in relational database management systems, and in applications and 
computer programs which support or interface to relational database management systems. 

It would be advantageous to obtain the advantages of object-oriented database man- 
agement, while retaining the efficiency of, and the installed invesmiem in, relational database man- 
agement systems. 

One problem which has arisen in the art is that the tools for creating, implementing, 
and manipulating object-oriented databases are generally inconsistent with the tools for creating, 
implementing, and manipulating relational databases. 

U.S. Patent 5,291,583, "Automatic Storage of Persistent ASN.l Objects in a Rela- 
tional Schema", issued March 1, 1994, in the name of inventor Subodh B^l, and assigned to Ra- 
cal-Datacom, Inc., and U.S. Patent 5,295,256, •'AutomaUc Storage of Persistent Objects in a Rela- 
tional Schema", issued March 15, 1994, also in the name of inventor Subodh Bapat, and also as- 
signed to Racal-Datacom. tac, show a method for compiling strucnires defmed using an ob- 
ject-oriented programming language, such as C-h- or Smalltalk, into a relational database sctucmre. 
However, while the method shovw in these patents generally achieves the goal of creating a rela- 
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tiona] database structure for persistent storage of objects, it is generally inadequate to tfie other tasks 
demaiKied of a database ^plicatioii, including dynamically modifying the object hierarchy and ob- 
ject relationships, populating the database, dynamically populating and editing the objects in the 
database, and dynamically generating and performing searches against the database. 

5 

The following patents are examples of the art; 



o U.S. Patent 5;}98,336, "Object-Oriented Architecture for Factory Floor Management" is- 
sued March 14, 1995, in the name of inventors Subhash B. Tantry, et al., and assigned to 
10 Consilitmi, Inc. 

o U,S. Patent 5,212,787, "Method and Apparatus for Accessing A Relational Database With- 
out Exiting An Object-Oriented Env^^onment^ issued May 18, 1993, in the name of in- 
ventors Ronald B. Baker, et al., and assigned to International Business Machines Corpora* 
15 tion. 

o U.S. Patent 5,201,046, ''Relational Database Management System and Method for Storing, 
Retrieving and Modifying Directed Graph Data Stmcnnes*', issued April 6, 1993, in the 
name of inventors Robert N. Goldberg, et al., and assigned to Xidak, Inc. 

20 

o U.S. Patent 5,181,162, ''Document Management and Production System'', issued January 
19, 1993, in the name of inventors Robert M. Smith, et al., and assigned to Eastman Kodak 
Company. 

25 o U.S. Patent 5,161,225, "Persistent Stream for Processing Time Consuming and Reusable 
Queries in An Object Oriented Database Management System", issued November 3, 1992, 
in the name of inventors Robert L. Abraham, et al., and assigned to International Business 
Machines Corporation. 

30 o U.S. Patent 5,133.075, "Method of Monitoring Changes in Attribute Values of Objects in 
An Object-Oriented Database", issued July 21. 1992, in the name of iiivehtor Tore JM. 
Risch, and assigned to Hewlett-Packard Company. 

3 



10 



wo 9604350 PCrAJS96/WW78 

o U.S. Patent 4,930,071 , "Method Sar Integrating A Knowledge-Based System with An Artri- 
traiy Database System'', issued May 29, 1 990, in the name of inventors Frederich K Tou, ct 
al., and assigned to IntelliCoxp, Inc. 

Accordbgly, it would be advantageous to provide a method of compilation an4 
translation between object-oriented and relational database structures which obtains the advantages 
of object-oriented database applications, while retaining the ability to use present relational data- 
base man^^ement systems* 

Summary of the InventioD 



The invention provides a method and system for modeling of object-oriented data- 
base structures, uanslation to relational database structures, and dynamic searches thereon. The 
invention thus allows a user to create, edh and manipulate a user's object databaise (vMch the 
1 5 method and system dynamically translates into a set of relational database stnicturcs), to create, edit 
and manipulate objects for that object database (which the method and system dynamicaUy trans- 
lates into data for those relational database structures), and to create, edit and manipulae queries to 
be applied to that object database (which the method and system dynamically translates into queries 
to be applied to those relational database structures). 

20 

The method and system includes a meta-model of the user*s object database, which 
is itself an object database, and which has itself been translated into a set of relational database 
stmcwres for manipulation by a relational database engine. The meta-model comprises a set of 
classes, objects, and relationships between classes which model the classes and relationships be- 

25 tween classes of the system. Each of these classes may comprise a set of searchable properties, and 
each of these relationships may comprise an inheritance relationship (between a base class and a 
derived class) or a data-model relationship (such as a one-to-one, one-to-many, or many-to-many 
relationship). The data model of the user's object database is modeled by actual objects in the 
meta-model, and editing or manipulating the user's object database is modeled by creating, modi- 

30 fying. or deleting objects in the meta-modcl. The meta-model also models itself, in the same man- 



4 



wo 96/34350 



PCT/US96/05678 



ner as it models the user's object database, and may be manipulated in the same manner as the 
user's object database* 

In a preferred embodiment, each class in the user's object database is modeled by a 
5 relational database table, each searchable property of that class is modeled by a colimm in that table, 
and each object of that class is modeled by a row in that table and corresponding rows in tables rep- 
resenting base classes for that object. Each such table comprises an ''object»ID'* colunm generated 
by the system, comprising a unique ID for each object in the system. Each relationship between 
two objects is modeled by providing a pointer from the first object to the second object; the pointer 
10 comprises a column (generated by the system to model the relationship) in the first objecfs table 
with the object*ID of the second object These relational database structures are created, modified, 
or deleted dynamically or incrementally in response to user conmiands to create, edit, and manipu- 
late the user's object database. 

15 At least two types of relationship are modeled by the system, inheritance relation- 

ships and data-model relationships. An inheritance relationship exists between a base class and a 
derived class. An object member of the derived class is entered in bodi the table for the base class 
and the table for the derived class, and it is given the same object-ID in both tables. The inheritance 
relationship between the two classes is modeled by a relational database JOIN between the two ta- 

20 bles on the ''object-ID** column. For multiple inheritance, an object with the same object-ID is en- 
tered in the derived class and in each of the multiple base classes. 

A data-model relationship is created by the tiser for the user's object database, and 
may comprise a one-to-one, many-to-one, or many-to-many relationship. One-to-one and many-to- 

25 one relationships are modeled by providing a pointer fitmi the first object to the second object 
Many-to-many relationships are modeled by providing a cross-link class, implemented using a table 
having one column for the first class having the object-ID of the first object in the many-to-many 
relationship, one column for the second class having the object-ID of the second object in the 
many-to-many relationship, and having one row for each pair of actually related objects. One-to- 

30 one and many-to-one relationships are modeled by a relational database JOIN between the two cor- 
responding tables on the column modeling the data-model relationship; many«to*many relationships 
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are modeled by a relational database JOIN between the tvwo corresponding tables and the cross-Uidc 
table, on the two cohmais modeling the data-model relationship. 

The method and system includes a query model whidj provides bs querying Ae 
5 user's object database widi a search that may be cascaded across multiple classes of objects. Hie 
user selects one or more classes to be searched, restrictions on searchable properties of objects iri 
those classes (such as having specific values for those searchable properties), and information to be 
presented for objects in those classes. In response to this search description, die system generates a 
relational database query (preferably comprising an optimized SQL command) to be applied to fte 
10 relational database strucmres corresponding to the user's object database, automatically including 
any commands needed to implement the inheritance relationships and data-model relationships of 
the user's object database. A preferred embodiment provides for automatic unit conversion of 
searchable properties' values. When the relational database query is applied to the relational data- 
base, the system receives information supplied fiom the relational database and presents it to the 
15 user according to displ^propeitiw of the classes which woe searched. 

In a preferred embodiment, the meta-model comprises a first set of predefined 
classes for modeling access control to aspects of the user's object database. Access may be re- 
stricted to selected users or to selected user groins, and may be specified for individual objects, 
20 classes of objects, or properties of tiiose objecte. In a preferred embodiment, the meta-model 
also comprises a second set of predefmed classes for modeling attachment of graphic and text 
objects to objects in the user's object database. Graphic and text objects may be associated with 
objects in the user's object database, and may be associated with system files and other objects 
maintained by an operating system in which the meta-model is embedded. 

25 

Brief Description of the Drawings 

Figure 1 shows a data model diagram of an example user's object database. 

Figure 2 shows a block diagram of a system for modeling of object-oriented data- 
30 base structures, translation to relational database strucmres. and dynamic searches thereon. 
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Figure 3 show a data model diagram of a meta-modei for modeling the user's ob- 
ject database. 

Figure 4 shows a data model diagram of a set of classes for modeling access control 
for the user's object database. 

Figure 5 shows a data model diagram of a set of classes for modeling predefined 
graphical information display for the user's object database. 

Figure 6 shows a flow diagram of a process for building and editing a data model of 
the user's object database. 

Figure 7 shows a flow diagram of a process for translation between object-oriented 
and relational database stmctures. 

Figure 8 shows a data model diagram of a user relational da t abase corresponding to 
the sample user's object database of figure 1 . 

Figure 9 refers collectively to figure 9A and figure 9B. Figure 9A shows a flow 
diagram of a process for cascade searching of an objea database and search translation between 
object-oriented and relational database structures. Figure 9B shows a block diagram of data struc- 
tures used in the process for cascade searching. 

Description of the Preferred Embodiment 

In the following description, a preferred embodiment of the invention is described 
with regard to preferred process steps, data structures, and user interface. However, those skilled 
in the art would recognize, after perusal of this application, that embodiments of the invention 
may be implemented using a genera! purpose computer, or a set of general purpose computers, 
operating imdcr program control, and that modification of a general purpose computer, or a set of 
general purpose computers, to implement the process steps, data structures, and user interface 
described herein would not require either invention or undue experimentation. 
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Exampue; Us£r*s OaiEcr Database 

Figure I shows a data model diagram of an example user's object database. This 
example is presented so as to support examples of modeling the object database, translation of the 
S object database into a relational database, and examples of database operations performed on the 
object database. 

An example user's object database 100 comprises a set of classes 101, each com- 
prising a set of searchable properties 102, and each representing a type of data for an ob- 

10 jea-oriented database to store, manipulate, or retrieve. The classes 101 fonn a hierarchy (more 
precisely, a directed acyclic grs^h), in \^ch each class 101 may be derived from zero or more base 
classes 101, and each class 101 may be a base class for zero or more derived classes 101. When a 
derived class 101 is derived from a base class lOlJt inherits all the searchable properties 102 of the 
base class 101, and may have additional searchable properties 102 particular to the derived class 

15 101. 

In this example, the object database 100 comprises a class 101 component which 
the semantics of the object database 100 define to be an electrical circuit component Each object 
of the class 101 component has a searchable property 102 ^'name", v^diich the semantics of the ob- 
20 ject database 1 00 define to be the name of that component 

In this example, the class 101 comix)nent is a base class, ftom which two classes 
]01 analog comix)nent and memory are derived. Because these two classes 101 are derived from 
the class 101 component they inherit all the properties of the class 101 component so eadi object 
25 of the class 101 analog component and each object of the class 101 memory also has a searchable 
property 102 *'name'\ In this example, each object of the class 101 memory has an additional 
searchable property 102 "size*'. 

The class 101 memory is also a base class, from which the two classes 101 dy^ainl^ 
30 memory and static memory are derived. Accordingly, ihey inherit all the properties of the class 101 
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memory and therefore also of the class 101 component so each object of the class 101 static mem- 
ory has 'iiaxne** and ''size" as searchable properties 1 02. 

Another example class 101 is manufacnirer . In this example, each object of the 
5 class 101 maniifacturer has "name** and "city" as searchable properties 102. h this example, the 
class 101 manufacturer is a base class, fiora which the classes 101 domestic manufacturer and for- 
eign manufiacturer are derived. The class 1 01 foreign manufacturer also has a searchable property 
102*'country*'. 

10 In this example, Ac class 101 comTX)nent has a data-model relationship 103 with the 

class 101 manufacturer. This relationship 103 is many-io-one; each object of the class 101 compo> 
nent has a related object of the class 101 manufacturer, while each object of the class 101 manu- 
facturer has zero or more related objects of the class 101 component . 

IS In addition to searchable properties 102, each object of a derived class 101 also in- 

herits the relationships 103 of its base class 101. Thus, each object of the class 101 static memory 
inherits the relationships 103 of the class lOI memory, which inherits the reladonships 103 of the 
class 101 comTx>nefit , One of the relationships 103 of the class 101 component is a relationship 103 
with the class 1 01 manufacturer, so each static memory has a manu&cturer. Similarly, each foreign 

20 manufiicturer may make static memories, dynamic memories, .and analog components. 

Those skilled in the art would easily recognize, after perusal of this application, a 
large number of variants on this example user's object database, and the ready applicability of the 
methods and systems disclosed herein to such variants. Applicability of the methods and systems 
25 disclosed herein would not require either invention or undue experimentation. 

System for Compilation and Translation 

Figure 2 shows a block diagram of a system for modeling of object-oriented data- 
base structures and translation to relational database structures. 

30 
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A system 200, for modeling of object-oriented database structures and tianslatum to 
relational database structures, comprises a user interfece 210 for receiving commands and descrip- 
tions from a user 201 . As shown herein, the commands and descriptions supplied by the user 201 
include descriptive information about the user's object database 100. The system 200 receives the 
descriptive information about the user's object database 100 and stores that informadon in a mcta- 
modcl 220 to represent a user database model 230. The mcta-modd 220 and the user database 
model 230 are themselves represented by structures in a relational database 250; the relational data- 
base 250 is implemented using a relational database engine 240. 

In a piefcned embodiment, the user interface 210 comprises a graphical user inter- 
fece 211 ("GUrO, having editing tools for creating and editing the user database model 230. 
Graphical user interfaces are known in the art, and those skilled in the art would recognize, after 
perusal of this application, that modification of a known computer system to implement the func- 
tions required of the GUI 21 1 would be straightforward, and would not require either invention or 
uxuiue experimentation. 

In a preferred embodiment, the user interface 210 also comprises alternative tools 
for entering the descriptive infcmiation about the user's object database 100. These alternative 
tools include a text description tool 212, having a text format for recording the descriptive infonna- 
tion, and disposed for reading that text format from a file or other software objects. Preferably, the 
text format is compatible with those written by othw programs, such as other database programs, to 
facilitate easy and rapid transcription of data to the system 200 from other sources. 

These ahcmativc tools also include an application programming interface 213 
("APn for supplying commands and descriptions of the user's object database 100 to the system 
200, having a set of programming constructs for providing an interfece between a program invoked 
by the user 201, and disposed for receiving program calls and date to use for creating and editing 
the user database model 220. Preferably, the API 213 has similar descriptive and imperative power 
85 the GUI 21 1, so that users 201 may invoke alternative programs for performing the same fimc- 
tionsastheGUI211. 
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The functions provided by the GUI 21 1, the text description tool 212, and the API 
2 1 3 are further described with regard to figure 6. 

The xneta-model 220 comprises an object database having as its objects the classes 
5 101 in the user's object database 100, searchable properties 102 of those classes, and reladonsbips 
103 between those classes. The meta-model 220 is further desmbed with regaid to figure 3. 

In a preferred embodiment, the relational database aigine 240 comprises a standard 
relational database management tool, such as the **Oracle** product available fiom Oracle Coipoia- 
i 0 tion of Redwood Shores, California. In alternative embodiments, the relational database ex^e 240 
may comprise a product which accepts relational database commands in the '^QL*" database ma- 
nipulation language, or another database manipulation language having similar descriptive and im* 
perative power* 

15 In a prefmed embodiment, the relational database engine 240 comprises a cli- 

ent/server, multi-user, nctwoiked architecture uhich uses a multi-user relational database engine, so 
that (1) a plurality of users 201 may operate on the relational database 250 simultaneously, (2) re- 
quests may be processed by the relational database engine 240, fiDm users 201 and from the system 
200, in an interleaved manner, and (3) a plurality of users 201 and a plurality of copies of the sys- 

20 tern 200 may be distributed over a network coupled to a plurality of relational database engines 240. 

Ruildinf the User Database 

The vser interface 210 receives conunands and descriptions from the user 201 re* 
garding the user's object database 100, and in response thereto, builds and edits the user database 
25 model 230. As the user database model 230 comprises a set of objects in the meta-model 220, the 
process of building and editing the user database model 230 simply comprises building and editing 
objects in the meta-model 220. These objects are maintained by the system 200 as persistent ob- 
jects, so the user database model 230 is maintained as a persistent part of the meta-model 220 by 
the system 200. 
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comprising a set of relational database tables, propenies of those tables, columns within those la- 
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bles, primaiy and secondary keys of those tables, and other defining feanires of the meta-model re- 
lational database 221. The user database model 230 is represented by objects in the meta-model 
leladonal database 221, comprising rows within those tables, specific values entered in the columns 
for those rows, and pointers firom a row of one table to a row of a related table. The process of 
building and editing the user database model 230, i.e, building and editing objects in the meta- 
model 220, simply cwnprises building and editing ckeses 101, objects, searchable properties 102 
and rchaionships 103 between classes 101, represented by rows, values and pointers in the meta- 
model relational database 221 v*ich represent the desaiptive infonnation about the user's object 
database 100. 

Since the meta-model 220 is also rei»esenied by the meta-model relational database 
221, a set of objects in the meta-model relational database 221 represent the meta-model 220 itself. 
TlHse objects in die meta-model relational database 221 representing the meta-model 220 m^ be 
edited just like the objects which represent the user database model 230. In fiict, the user database 
model 230 may be buih and edited simply by editing the objects in the meta-model 220. Even the 
strucniie of the meta-model 220 may also be edited by editing the objects in the meta-model 220. 

In response to a triggering event, the system 200 translates the user model 230 into a 
user relational database 231, using a set of SQL commands 232 for specifying and creating reto- 
tional structures in the user relational database 23 1 . Tbese SQL commands 232 specify relational 
database tables, properties of those tables, columns within those tables, primary and secondary keys 
of those tables, and other defining feamies of the user relational database 231. These SQL com- 
mands 232 are transmitted to the relational database engine 240. which then specifies and creates 
the user relational database 231 . 

In a preferred embodiment, the triggering event for translation of the user database 
model 230 comprises a command by the user 201 to the GUI 21 1, or by a program invoked by the 
user 201 to the API 213, to create the user relational database 231. However, alternative triggering 
events, such as a timed automatic save, or a sufficient change in the user database model 230. are 
also recognized by the system 200. When the user database model 230 is specified using the text 
description tool 212, the triggering event may comprise a triggering command in a text file Itself, an 
end of file condition, such as having no more text to translate, or another condition. 

12 
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The process for translation between object-oriented and relational database stmc- 
tuies is fistfaer described with regard to figure 7. 

S Populating the 1 Tser Database 

The user interface 210 also receives commands and descriptions fiom the iiser 201 
regarding populating objects for the user database model 230, corresponding to objects for the 
user's object database 100. In response thereto^ the system 200 builds and edits data items for the 
user relational database 232, following the specifications in the user database model 230. 

10 

The system 200 translates the objects for the user database model 230 into a set of 
SQL commands 233 for inserting, modifying, or deleting rows in the tables of the user relational 
database 231. These SQL commands 233 are transmitted to the relational database engine 240, 
which creates and edits rows within those tables, specific values for the columns for those rows, 
IS and pointers from one table to a related table. 

In a preferred embodiment, the tiser 201 may specify integrity checks for each class 
101 in the user database model 230, such that when an object is added to the user relational data- 
base 231 , the integrity check is performed and the object is assured to meet the integrity check. For 
20 example, in the example user's object database 100 shown in figure 1, the user 201 may specify that 
each object of class 101 component has one and only one associated object of class 101 manu- 
facturer . In this example^ the user 201 may specify this integrity check in the data-model rela:; 
tionship 103 between the class 101 component and the class 101 manufacturer . 

25 Similarly, the user 201 may specify a set of enumerated values, or a range of values, 

as the only valid values for a searchable property 102. When the user 201 so specifies* the system 
200 creates an object, as further described herein with reference to figure 3, describing the valid set 
of enumerated values or the valid range of values, and associates that object with the searchable 
property 102. 

30 

In a preferred cmbodimenu the user interface 210 provides the user 201 with a 

command to show the valid set of enumerated values or the valid range of values for a searchable 

13 
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property 102, before entering a value for that searchable property 102 for a particular otgecL This 
allows the user 201 to determine which values are sppropriate for dial searchable prqiei^ 102 be- 
fore populating an object with a new value. When the user 201 has abeady entered values for other 
searchable properties 1 02 of the object, the user interface 210 optionally specifies only tiiose values 
already in the database for objects having the same values for those other searchable properties 102. 
For example, in the example user's object database 100 shown in figure 1, if Ae user 201 is creat- 
ing an object of class 101 memory, has already entered a value for the searchable property 102 
••name" for the associated object of class 101 manufacturer, and is about to enter the value for the 
searchable property 102 "size", the user 201 may request the user interface 210 to display all the 
values for "size" which already exist for memories with that manufacturer. 



In addition to integrity checking, the user 201 may specify "business rules," i.c., ex- 
tension fimctions to be executed when an object of a specified class 101 is created or destroyed. 
For example, the user 201 may specify a searchable property "Serial Number" for objects of class 
15 101 cftmtMnent. with the business rule that the system 200 creates a unique new serial number 
whenever a new object of that class 101 is created. Extension functions for classes 101 (class func- 
tions) and for searchable properties 102 (class property fimctions) are further described herein with 
reference to figure 3. 

20 Querying the 1 Iser Database 

The user interfece 210 also receives commands and descriptions fiom the user 201 
regarding querying or searching the user's object database 100 (i.e.. for querying or searching the 
objects in the user relational database 231). In response thereto, the system 200 builds and edits a 
query model 260 for a query to be applied to the user relational database 231. The process of 
25 buUding and editing the query model 260 is further described herein with regard to figure 9. 

In response to a uiggering event, the system 200 translates the query model 260 into 
a set of SQL commands 261 for querying (including SQL query features such as grouping and 
sorting) the user relational database 231. These SQL commands 261 arc transmitted to the reU- 
30 tional database engine 240, which applies the query to the user relational database 23 1 . generates a 
set of queiy results 251 from the query, and returns that set of query results 251 for presentation to 
the user 201. 

14 
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In a preferred embodiment, the triggering event for translation of the queiy model 
260 comprises a command by the user 20 1 to the GUI 2 1 1 , by a text command to the text descrip- 
tion tool 212, or by a program invoked by the user 201 to the API 213, to create the query results 
5 251 , The query model 260 also comprises descriptive information regarding presenting the results 
of the query to the user 201, which is incorporated by the system 200 into the SQL commands 261 
forthcquery. 

The process for creation of the query model 260 and translation of the queiy model 
1 0 260 into a relational database query is furtho- described with regard to figuie 9. 

Meta-Model FOR MoDExiNG THE User's Object Database 

Figure 3 shows a data model diagram of a meta-model for modeling the user's ob- 
ject database. 

15 

The meta-^odel 220 comprises a set of classes 101, a set of searchable iHoperties 
102 for each class 101, and a set of relationships 103 between classes 101, thus forming a syston 
object database for recording information about the user's object database 100. 

20 In figure 3, each box represents a class 101 and each line between boxes represents a 

relationship 103 between classes 101. 

At junctions between classes 101 and relationships 103, symbols represent whether 
the relationship 103 couples zero, one, or more than one, objects of that class 101. A symbol has 
25 two symbol parts; a circular symbol part indicates zero objects, a single line symbol part indicates 
one object, and a forked line symbol part indicates more than one object. Thus a single symbol may 
indicate, for example, that each object in a first class 101 corresponds to one or more objects in a 
second class 101. 

30 A shaded box represents a cross-link class lOL whose purpose is to provide for a 

many-to-many relationship between objects. Each such class 101 has rwo or more relationships 

15 
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103, at least a first many-io-onc relationship 103 to a lim class 101 and a second many-to-onc lela- 
tionship 103 to a second class 101. Thus, each object in a cross-link class 101 comprises at least an 
onicit^ pair of Clements, one object fiom the fim clas^ 
101, and represents a onc-toK)nc relationship 1 03 between those two objects. 

^^f^.\Af^^^ Classes 

In a preferred embodiment, the meta-model 220 comprises classes shown in table 3- 

1. 



10 



IS 



Class 
Class 
Class Link 

Pointer Class Property 



Pointer Valid Class 



Class Property 

20 

Property Group 

Logical Datatype Definition 



Enumerated Valid Value 
25 Range Valid Value 
Unit of Measurement 
Unit Conversion Formula 



30 



Table 3-1 
Descrippon nf Object in Class 
class modeled by the meta-model 
cross-link class between parent/child classes 
searehable property modeled by a pointer to another class, 
having a delete, insert, and update nilcs associated wiA Ac 
pointer 

relationship between pointing object and object of target 
class 

searehable property modeled by the meta-model, hawig 
built-in type of value 
related group of properties 

logical data type for property 

set of enumerated valid values for property 

range of valid values for property 

unit of measurement for property 

formula for converting between source and target unit of 
measurement 



Class Property Function Operation 

Class Function Operation 
Custom Function Definition 



member function defined for a class property 
member ftmciion defined for a class 
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Fofinula 
S Configuration 



user-specified fimction 

External Access Function Operation 

function which calls on the operating system 
algebraic formtila 

description of how an object is displayed, such as a configu- 
ration for editing an object 

Search Panel Configuration 

configuration for a search 

Results Panel Configuration 
] 0 configuration for displaying search results 



The user^s object database 100 comprises a set of classes 101. In the meta-model 
220, each class of the user's object database 100 is modeled by an object of class Class 30L 

15 In a preferred embodiment, each object of class Class 301 comprises information in 

table 3-2. 



Property 
20 Object ID 
Class Label 
Class DB Name 



25 



30 



Class Group 



Class Type 



Is System Specific 
Number of Objects 



Table 3-2 
Description 

unique ID for this object 

name to be displayed for the class 

unique name for the class to be used in the user relational 
database 

indicates vrfiether the class is part of the meta-model, a fm- 
defined class provided by the system, such as for graphics or 
permissions, or a user class 

indicates vv4iether the class is part of the meta-modeU a cross- 
link class, a base class created for the sole purpose of group- 
ing derived classes under a single "folder" name, or any other 
class created by the user 
TRUE if this class is part of the system 
number of objects currently in this class 
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Number of DB Blocks number of database blocks cunendy used by this class 

Max # of Objects raaximum number of objects eiqsected for the class 

Class Description description of the class, for user convenience 

Pending Operation indicates the next operation pending for the class, e.g., create 

relational table, modify relational table, recreate relational 
table, or no action pending 
p^^QJ^ indicates an action being taken for this class, eg., executing 

tiie "Pending Operation", altering display configuration, re- 
freshing an Oracle "view", counting the number of objects in 
the class, or no action being taken 

The property 102 "Class DB Name" is generated by the system 200, and is prefera- 
bly required to satisfy name restrictions imposed by the relational database engine 240, such as be- 
ing limited to a certain length or to having only certain characters. The "Class DB Name" is used 
by the system 200 for generating SQL commands for accessing relational structures corresponding 
to this class 101, such as the SQL commands 232, 233, and 261. In a preferred embodiment, the 
user 201 may override the "Class DB Name" generated by the system 200, but must still satisfy the 
name restrictions imposed by Ac relational database engine 240. 

The properties 102 "Class Group", "Class Type", and "Is System Specific" maintain 
information about the purpose of the class 101 in the system 200. If the user 201 modifies a class 
101 which is critical to operation of the system 200, such as a class 1 01 which is part of the meta. 
model 220, the qrstem 200 warns the user 201 and requests confirmation that the action is truly in- 
tended. 

The property 102 "Max # of Olgects" is provided by the user 201, although this 
property 102 does not impose a hard limit of any kind, and is just a suggestion by the user 201, and 
the system 200 preferably provides a defauh value and a pn>ceduie for extension when the number 
of objects exceeds this property value. The properties 102 "Number of Objects" and "Number of 
DB Blocks" arc provided by the system 200. These properties 102 are used for improving the sys- 
tern's efficiency in creating or searching tables using the relational database engine 220, as shown 
herein with reference to figure 9. 
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The properties 102 ''Pending Operation" and **Action** maintain infonnation about 



the status of the class 101 with regard to its representation in die relatioiud database 250. If there is 
more than one user 201 simultaneously using the system 200 (this is the preferable operation of the 

5 system 200), it may occur that more than one user 201 attempts to simultaneously modify the same 
class 101. The system 200 uses these properties 102 to assure that such attempts do not cause any 
class 101 to enter an inconsistent state. Those skilled in the art of database systems will recognize 
that there are many known techniques for maintaining database integrity despite simultaneous up- 
dates of a database system, and will recognize, after perusal of this application^ that application of 

1 0 such techniques to the system 200 would not require either invention or undue experimentation. 

Parmt/^^hild Classes 



(base classes from which that class is derived), and zero or more child classes (derived classes for 
IS \>^ch that class is a base class). In the meta-model 220, each object of class Class 301 may have 
zero or more parent objects of class Class 301, and may have zero or more child objects of class 
Class 301. These many-to-many parent/child class relationships 103 are represented using a cross* 
link class Class Link 302. 

20 Each object in the class Class Link 302 links a child class 101 to a parent class 101. 

A child class 101 may have more than one parent class 101 due to multiple inheritance. 



In the user's object database 100, each class comprises zero or more parent classes 



In a preferred embodiment, each object of class Class Link 302 comprises informa- 



tion in table 3-3. 



Table 3-3 



Property 
Object ID 
Parent Class 



Description 



30 Child Class 



imique ID for this object 
object ID for parent class 
object ID for child class 



Distributed DB Node 



node in a distributed database for which this object is a link 
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The seatcfaable jaopaty 102 "Distributed DB Node" identifies a node in a distrib- 
uted database. When an objert of class S^iM 302 has a link to another iwdem a distrib^ 
database, the searchable property 102 "Distributed DB Node" for that object is set to identify the 
other node, and the system 200 responds to Aai link ly attempting to spawn a related process at the 
5 linked-to node. Thus, the user 201 can perform relational database JOIN operations, and cascade 
searches, across multiple nodes of a distributed relational database 250, 

When the user 201 creates a derived class 101, or alters the base/derived status of a 
class 101, the system 200 creates or edits an olqect of class Class Link 302 to model the 
10 base/deiived relationship. 

^'■r^f^h Frnerties 

The user's object database 100 conqaises a set of searchable properties ftw eadi 
class. Searchable properties may comprise data values which are "built-in" data types, such as int^ 
15 gcrs and floating-point numbers, or may comprise data vahies which are themselves user-defined 
data types, represented as objects in user-defined classes. In the meta-model 220, searchable prop- 
erties comprising built-in data types are represented by a class Class property 303. whUe searchable 
properties comprising user-defined data types (implemented by pointers to objects of the user- 
defined data types) are represented by a class 101 Poii^ter Class Property 304. 

20 

The class Class 301 has a relationship 103 to the class PointcT Class Property 304 
v^ch links a class 1 01 to its searchable properties with user-dcfmed data types. The class PaialS 
nass Property 304 has a relationship 1 03 to the class Pointer Valid Class 305, and the class Psiffla 
YaliiQass 305 has a relationship 103 to the class 301, which link a searchable property 102 
25 with a user-defined data type to the class 101 defining that data type. 

gpaw-ha ^li^ Properties: User-De fined Datatypes 

The class PnintPr riass Property 304 includes one object for each searchable prop- 
erty 102 for any object of class Class 301 having a user-defined dau» type, and each object of class 
30 Qm 301 may have zero or more associated objects of class Pointer Class Property 304. Each ob- 
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ject of class Pointer Class Property 304 has a pointer to an object of the user-defined type; the 
pointer is an obtect of class Pointer Valid Class 30S. 

In a prefened embodiment, each object of class Pointer Class Property 304 com- 
S prises information in table 3-4. 



Property 
Object ID 
1 0 Pointer Property Label 
Pointer Property DB Name 

Display Order 

15 Is Owned by Target 

Is Value Required 
Is Column Indexed 

20 Column Index Type 
Is Derived Externally 
Relational Meaning 



25 



Configuration Info 



Insert Updaie Rule 



30 Delete Rule 



Table 3-4 
Description 

unique ID for this object 

name to be displayed for the property 

unique name for the property to be used in the user relational 

database 

order this property is displayed xeiative to others within its 
class 

TRUE if this property inherits pemiission from the class it 
points to 

TRUE if value cannot be null 

TRUE if column for this property is indexed in the user rela- 
tional Hatflj-in^^ 

type of index in the relational database 
TRUE if generated by system 

relational meaniiig of properly in the user relational database, 
e.g., primary key, internal key, description 
indicates when this property is displayed: for searches, for 
search results, for both, or for neither 
rule to follow when inserting or updating new objects having 
this property, e.g., disallow updates if there are related ob- 
jects, cascade update to any related objects, or set pointer to 
null on update of related objects 

rule to follow when deleting objects having this property, 
e.g., disallow deletion if there are related objects, cascade 
deletion to any related objects, set pointer to null on deletion 
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of related objects, or set pointer to de&uh value cm deletion 
of related objects 

Pending Operation indicates the next operation pending for the propeity, eg., 

alter relational database dictionary, or no action pending 

Number of DB Blocks number of database blocks used by the relational column for 

thispropeity 

Row Selectivity measure of distribution of values in the relational column for 

thispropeity 

Block Selectivity measure of distribution of values, at DB block level 

Pointer Description description of the property, for user convenience 

Similar to the property 102 "Class DB Name", the property 102 'Tointer Property 
DB Name" is generated by the system 200, and is preferably required to satisfy name restrictions 
imposed by the relational database engine 240, such as being limited to a certain length or to having 
only certain characters. The "Pointer Property Class DB Name" is used by the system 200 fc^ gen- 
erating SQL commands for accessing relational stnicmres corresponding to this property 102, such 
as the SQL commands 232. 233, and 261. In a preferred embodiment, the user 201 may override 
the "Pointer Property DB Name" generated by the system 200, but must still satisfy the name re- 
strictions imposed by the relational database engine 240. 

The properties 102 "Display Order" and "Configuration Info" arc merely default 
values for the property 102, and may be overridden by the user 201 for specific display configura- 
tions or searches. 

The properties 102 ^'Number of DB Blocks". "Row Selectivity" and "Block Selec- 
tivity^ are computed by the system 200. These properties 102 are used for improvir^ the system's 
efficiency in searching tables using the relational database engine 220. 

In a preferred cmbodmicnt, each object of class PointyT Valid Class 305 includes 
information in table 3*5. 

Table 3-5 
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Object ID 

Valid Class Description 



Descnption 

unique ID for this object 

description of the relation between the pointing and target 
classes, e.g^ in ' *part is*manufactured*by manufacturef *. the 
Valid Class Description would be 'is-manufactured-by* 



Each object of class Pointer Valid Class 305 links an object of class PointCT Class 
Property 304 to a target class lOL 

10 Searchable Properties: Built-in Datatypes 

The class Class Property 303 mcludes one object for each searchable property 102 
for any object of type class having a built-in data type« and each object of class Class 301 may have 
zero or more associated objects of class Class Property 303. Eadi object of class Class Property 
303 has a value. 



15 



In a preferred embodiment, each object of class Class Property 303 comprises in- 
fonnation in table 3*6. 



20 Property 
Object ID 
Property Label 
Property Data Type 

25 Property DB Name 

Display Order 

Display Type 



30 



Display Length 
Display Precision 



Table 3-6 
Description 

unique ID for this object 
name to be displayed for the property 
indicates data type this property is stored as: boolean, char- 
acter, date, integer, monetary, numeric, or timestamp 
unique name for the property to be used in the user relational 
database 

order this property is displayed relative to others within its 
class 

indicates data type this property is displayed as: boolean, 

character, date, integer, monetary, numeric, or timestamp 

space allocated to displaying this property 

number of digits for displaying this property 
23 
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Case Style 

Visible Rows 
Relational Meaning 

5 

Configuration Info 

Default Value 
Is Value Required 
10 Is Column Indexed 

Column Index Type 
Valid Value Type 

15 Is Derived Externally 
Is Comma Displayed 

Is Scientific Notation 

20 Pending Operation 

Number of DB Blocks 



25 



Row Selectivity 

Block Selectivity 
Property Description 



for text vali^s only, either always lower case, always iq)per 

case, case insensitive, or case sensitive 

number of rows for displaying this property 

relational meaning of property in the user relational dat abas e, 

e.g., primary key, internal key, description 

indicates when this property is displayed: for searches, for 

search results, for both, or for neither 

value when not specified by the user 

TRUE if value cannot be null 

TRUE if column for this property is indexed in the user rela- 
tional database 

type of index in die relational database 

indicates if value is restricted to certain valid values, e.g., 

enumerated valid value or range valid value 

TRUE if generated by system 

for numeric values only, TRUE if a comma is displayed to 
separate thousands 

for numeric values only, TRUE if displayed in scientific no- 
tation 

indicates die next operation pending for die property, e.g., 
alter relational database dictionary, or no action pending 
number of database blocks used by the relation^ column for 
this property 

measure of distribution of values in die relational column for 
this property 

measure of distribution of values, at DB block level 
description of die property, for user convenience 



Similar to die property 102 "Class DB Name", die property 102 -'Property DB 
30 Name- is generated by die system 200, and is preferably required to satisfy name restrictions im- 
posed by die relational database engine 240, such as being limited to a certain Icngdi or to having 
only certain characters. The "Property Class DB Name" is used by die system 200 for generating 
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SQL commands for accessing relational stnictures coiresponding to this property 102, sudi as the 
SQL commands 232, 233, and 261. In a preferred canbodiment, the user 201 may ovenide the 
''Property DB Name'* generated by the system 200, but must sdll satisfy the name restrictions im- 
posed by the relational database engine 240. 

5 

The properties 102 "Display Order" "Display Type*', "Display Length", "Display 
Precision'*, "Visible Rows" and "Configuration Info** are merely default values for the property 
102, and may be ovexridden by the user 201 for specific display configurations or searches. 

10 The properties 102 "Number of DB Blocks'*, "Row Selectivity** and "Block Selec- 

tivity^ are computed by the system 200. These properties 102 are used for improving the system's 
efficiency in searching tables using the relational database engine 220. 

A class Property Group 306 includes one object for each type of searchable property 
IS 102, and each object of class Class Property 303 may have zero or more associated objects of class 
101 Property Group 306, Each object of class Property Group 306 has a group name. The class 
Class Property 303 has a relationship 103 to the class Property Group 306 vs4iich Ihoks a group of 
properties into a single folder class 101 . 

20 Searchable Property Data Values 

In the user's object database 100, a searchable properly 102 of the class Class Proiv 
erty 306 may have a spedfic logical data type, such as integer or floating point In the meta-model 
220, a class I^pical DaXztvpe Definition 307 includes one object for each logical data type, and 
each object of class Class Property 303 is associated with no more than one object of class Lorical 
25 Datatype Definition 307. 

In a imferred embodiment, each object of class Logical Dat at\T)e Definition 307 
comprises informadon in table 3*7. 



30 Table 3-7 

Property Description 

Objea ID unique ID for this object 
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Logical Datatype Name 
DBMS Data Type 
DBMS Data Type Length 
Data Storage Precision 
5 Datatype Description 



10 



15 



20 



25 



name to be disp layed for the data type 
name of data type as defined by relational database ffigjne 
length of data type as defined by relational database engine 
maximum number of digits to right of decimal point 
description of the data type, for user convenience 



In the user's object database 100, a searchable property 102 of the class QasJEsSB: 
city 303 may have its value restricted to a specific rai^c or to a specific set of enumerated values. 
In the meta-model 220, a class Fnumerated Valid Value 308 includes one object for eadi set of 
enumerated valid values, and each object of class Class Property 303 is as^iated with zero or 
more objects of class Fm,merated Valid Value 308. SimUariy, a class Ranpe Valid Value 309 in- 
cludes one object for each set of range valid values, and each object of class Class Propefty 303 is 
associated with zero or more objects of class Range Valid Value 309. 

In a prefened embodiment, each object of class Fmmierated Valid Value 308 com- 
prises information in table 3-8. 



Property 
Object ID 
Enumerated ValiK 
Valid Value Name 
Cascade Flag 



Tablc3.8 . 
Description 

unique ID for this object 

valid lookup value 

name for valid lookup value 

TRUE if valid lookup value is cascaded to derived classes 



The property 102 "Cascade Flag" describes whether, when the object of class £nu: 
^^..A v^tid Value 308 is associated with a property 102 for a base class lOK whether the enu- 
mcialed valid values are cascaded to the same property 102 for objects of derived classes 101 which 
arc derived from that base class 101. For example, in the example user's object database 100 
shown in figuie h the user 20 1 may specify a searchable property 1 02 '^Serial Number" for the class 
30 101 mmm^ ^ "P^^ « ^ enumerated valid values for the class lOl coynpopent . 
Although this searchable poperty 102 ^Serial Number" is inherited by each derived class 101 of 
the base class 101 component such as the class analog componem and the class 101 mSDSEL. the 
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xiser 201 may desiie that these derived classes 101 have distinct sets of enumerated values for their 
own serial numbers. 

The class Enumerated Valid Value 308 has a first relationship 103 wifli the class 
S Class 301 and has a second relationship 1 03 with the class Class Property 303. 

In a preferred embodiment, each object of class Range Valid Value 309 comprises 
information in table 3-9. 

10 Table 3-9 

Property Description 

Object ID imique ID for this object 

Minimum Value liiinimum valid value 

Maximtmi Value maximum valid value 

is Default Value definilt value if none specified 

Cascade Flag TRUE if valid lookup value is cascaded to derived classes 

Similar to the property 102 "Cascade Flag" for the class Enumerated Valid Value 
308, the property 102 '"Cascade Flag"^ describes whether, when the object of class Range Valid 

20 Value 309 is associated with a property 102 for a base class 101, whether the range of valid values 
are cascaded to the same property 102 for objects of derived classes 101 which are derived 6om 
that base class 101. For example, in the example user's object database 100 shown in figure U the 
user 201 may specify a searchable property 102 "Serial Number** for the class 101 componenL and 
may speciiy a range of valid values for the class 1 01 component Although this searchable property 

2S 102 "'Serial Number^ is inherited by each derived class lOI of the base class 101 comnonenL such 
as the class analog component and the class 101 memory , the user 201 may desire that these derived 
classes 1 01 have distinct ranges of values for their own serial numbers. 

The class Range Valid Value 309 has a first relationship 103 with the class Class 
30 30 1 and has a second relationship 1 03 with the class Class Property 303 . 



Units of Measurement 
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fa thf \i?rr*« ^>j«-> riatftKage 100, a scmhAle jpropertv 102 of the class Class Prop- 
CTtY 303 may have its value expressed in a designated unit of measurement. In the tnetarmodel 220, 
a class Unit of Measurement 310 includes one object for each mut of measuremem, and cadi object 
of class riaqj^ Property 303 is associated (for display) with at most one objects of class IMjjf 
Measurement 310, and is also associated (for storage) with at most one objects of class UiaLsf 
Measurement 310. 

In a preferred embodiment, each object of class Unit of Measurement 310 comprises 
information in table 3-10. 

Table 3-10 

Prot>ertv Description 
Object ED unique ID for this object 

UOM Name name of the unit of measurement 

15 UOM Display Symbol symbol to be displayed for the unit of measurement, e.g., 

UOM Description description of the unit of measurement, for user convenience 

In the user's object database 100, a first unit of measurement may be converted to a 
20 second unit of measurement For example, to convert volts to miUivolts, multiply by 1,000. In the 
mcta-modd 220. a class Unit Conversion Formuia 311 includes one object for each fonnula for 
converting units of measurement, and each object nf r la^^ l Init Conversion Formula 311 is associ- 
ated (for source units) with zero or more objects of class Unh nf Measurement 3 10, and is also as- 
sociated (for target units) with zero or more objects of class Unit of Measurement 310. 

25 

Ciiirt ^n^ Functions 

Custom functions provide a technique for dynamic modification of objects in the 
system 200, including objects in the meta-model 220. Those custom fijnciions are triggered by in- 
sertion events, modification events, and deletion events. The user 201 specifies the actual changes 
30 performed by the system 200 when custom ftmctions are invoked. 
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The meta-model 220 comprises several additional classes 101 embodying objects 
for computation, class Class Prope rty Function Operation 3 12, class Class Function Operation 313, 
class Custom Fun ction Definition 314, class External Access Function Operation 315, and class 
Formula 3 16. 

5 

The class Unit Conversion Fomula 311 has a first relationship 103 with the class 
Unit of Measurement 310 for a source unit of measurement, a second relationship 103 with the 
class Unit of Me asurement 310 for a target unit of measurement, and a relationship 103 with tiie 
class Formula 3 16 for the conversion formula. 

10 

An object of class Formula 316 comprises an algebraic formula, and includes a for- 
mula name, an addend, a multiplier, an add/multiply rule (addL multiply, add then multiply, or mul- 
tiply then add), and a formula description. 

IS Objects of class Class Property Function Qperaticm 312 and nf ciass r}si^ pimrrinn 

Operation 313 comprise information about functions to be performed in addition to, or in place of, 
an operation for the relational database 250, and includes an operation sequence (e.g., defined in 
terms of calls on the operating system), and a DBMS operation which the custom function adds to 
or substitutes for. 

20 

An object of class Custom Function Defim'tion 314 comprises information about a 
custom function, and includes a fiincuon name, a version number, a function description, a flag to 
force execution of the custom function when an object of a class 101 related to the custom fimction 
is created, and a flag to override a custom fimction for a base class 101 when an object of a derived 
25 class 101 is created. A custom fimction adds or overrides a class member fimcuoru for a class 101 
or an object in a class 1 01 , and may be specified to override the class member function either before 
or after the class member function's ordinaiy operatioa 

An object of class External Access Function Operation 315 comprises information 
30 about a fimction for accessing an object u^ich is external to the system 200« such as a file system 
object, an external database, or another object accessed by calls on the operating system. 
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r^iocc T«fnrTnat^on Displav 

In a prefcired embodiment, a class Clas ^ Configuration 320 includes one object for 
each description of a display configuration of a class 101 in the user's object database 100. Each 
object of class riass Configuration 320 is related to zero or more objects of class geaich Pan^ Qop- 
5 figuration 321, a class 101 including one object for each display configuration for searches on the 
class 1 OU and is related to zero or more objects of class R«tilt Pane Configuration 322« a class 101 
including one object for each display configuration for results of searches on the class 101 . 

In a preferred embodiment, each object of class Search Pane Configuration 321 and 
10 each object of class Result Pane Configuration 322 comprises infoimadon in table 3-11. 
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Table 3-11 


ProDcitv 


Pescripti^n 


Object ID 


unique ID for this object 


Display Type 


data type for display of the field 


Display Widtfi 


maximum displi^ width for tiie field 


Display UOM 


unit of measurement for di^lay 


Row Order 


relative order for displaying row 


Column Order 


relative order for displaying column 


Custom Label 


label for displaying the field 



Each object of class Search Pane Configuration 321 and each object of dass ESSiU 
Panp ronfiguiation 322 is also associated with zero or more objects of class Qm 301 and with 
zero or more objects of class Class Property 303, to define the classes and class properties to be 
25 displayed. 



ACCESS Control 



Figure 4 shows a data model diagram of a set of classes for modeling access control 
for the user's object database. 

30 
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la a prefeired embodiment the set of classes shown in figure 4 arc predefined for 
the system 200. However, unlike the meta-model 220, these classes 101 are provided for con- 
venience in modeling access control, and are not strictly required for modeling, translation, or 
searching the user's object database 100. 

5 

A class Root 401 is a base class 101 for all classes 101. In a preferred embodi- 
ment, the class ^oot 401 has only a few searchable properties which are generic to all objects in 
the system 200, such as a signature of the last creator or last modifier of the object, a timestamp, 
an is-private flag for indicating whether the object is private to a particular user 201, and a tern- 
10 plate identifier, if the object is a member of a class template. The class Root 401 is provided so 
that relationships 103 with the class Root 401 are inherited by all classes 101. 

An object of class User 402 represents an individual user of the system 200, and 
includes information about the user, such as a user name, user password (possibly encoded for 
IS security), "super user*' status, mailing address, telephone number, and accounting information 
such as who is responsible for user charges. 

An object of class User Group 403 represents a group of users of the system 200, 
all having similar access control rights. User groiqss form a parent/child hierarchy (more pie- 
20 ciseiy, a directed acyclic graph) like the parent/child relationship of classes 101. The class User 
Group 403 has a many-to-many relationship with itself using the cross-link class User Group to 
User Group 404, which represents the user group parent/child hierarchy. 

The class User 402 and the class User Group 403 have a many-to-many relation- 
25 ship using the cross-link class User to User Group Link 405, which represents zero or more us- 
ers' membership in zero or more user groups. 

Access control is provided by two features. The first feature is ownership of a 
class property or an individual object, which ownership is by a user group or a user. (A user 
30 group may also own an entire class.) The second featwe is edit permissions for a class or an in- 
dividual object, which edit pennissions are by a user group or a user. 
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Ownership is represented by the cross-link class User Group to Class Ownership 
406, the cross-link class User Group to C lass Prppertv Ownership 407, the cross-link class UsSL 
Hmii p m Object Ownership 408, the cross-Unk class User to Class Property Ownership 409, and 
the cross-link class User to Object Ownership 410, Ownership is thus a many-to-many relation- 
ship which links classes, class properties and objects with their user group and user owners. 

Edit permissions are represented by the class User Group to Class Object Edit 
Permission 41 1, the class User Group to Object Edit Permissions 412, the class \}ser p C>a?s 
nk j^t VA\i Permission 413. and the class User to Objec t VAh Pemiission 414. Edit permissions 
are also a many-to-many relationship which links class properties and objects with user groups 
and users having permissions, except that for each such relationship the specific edit permissions 
are listed in an edit permissions object. 

GRAPHICAL INFORMATION DISPLAY 

Figure 5 shows a data model diagram of a set of classes for modeling predefined 
graphical information display for the user's object database. 

In a preferred embodiment, the set of classes shown in figure 5 are predefined for 
the system 200. However, unlike the meta-modcl 220, these classra 101 are provided for con- 
vcnicncc in modeling predefined graphical information, and are not strictly required for model- 
ing, translation, or searching the user's object database 1 00. 

An object of class Graphics 501 comprises information about a predefmed graph- 
ics object. The class Graphics 501 is related lo the class Root 401 by a cross-link class Graphic^ 
tf. Object Link 502, defining a many-to-many relationship in which any object may be sharably 
attached to any graphics object, and any graphics object may be sharably attached to any object 
The class Graphics 501 is also related to the class Root 401 by a many-to-one relationship 103. in 
which a graphics object may be a non-shared attachment of any object. 

An object of class Alias Variable 503 comprises information about a file accessi- 
ble using the operating system. The class Graphics 501 is related to the class Alias Variable 503 
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by several many-to-one relationships 103, one each for files used by the operating system to im- 
plement the graphics object Similarly, an object of class Binary Large Object 504 comprises a 
binaiy large object implemented by the operating system, and is associated with zero or more 
graphics objects. 

5 

The class Graphics 501 is also related to the class User 402 by a many*to-one re- . 
lationship 103, in which a graphics object may be "checked out" or **checked in** (as a library 
book) by a user. When a graphics object is "checked out,** no other user 201 of the system 200 is 
allowed to access that graphics object imtil it is "checked in" again. This allows the user 201 to 
10 check out a graphics object, atomically update it, and check the ^phics object back in, when it 
will again be available to other users 201 . 

An object of class Locale 505 comprises a logical location, such as a country. 
Zero or more locations may be related to a currency, represented by an object of class Unit of 
IS Measurement 310, and to an object of class Tlmezone 506. An object of class Locale 505 in- 
cludes a language identifier, a currency symbol and its placement, numeric formats (e.g., a digit 
separator, a date format, a time format, a radix point), and words for "false'* and **true**. Zero or 
more users may be associated with a single locale. 

20 An object of class Infomation Text 507 comprises textual information about any 

object. The class Information Text 507 is related to the class Root 401 by a many-to-one rela- 
tionship 103, in which textual information may be attached to any object. An object of class lih 
formation Text Tvpe 508 comprises a type descriptor for textual information (e.g., *'e-mail** or 
'*memo**). The class Information Text Type 508 is related to the class Information Text 507 by a 

25 many-to-one relationship 103. 

The system 200 also provides a "note'* which may be attached to each object. If 
the textual information to be associated with an object is short, e.g., just a few lines of text, the 
user 201 may simply add a "note** to the object, such as a short comment or reminder. This fea- 
30 ture saves the user 201 having to create a searchable property 102 for notes to be associated with 
the object. 
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An object of class Activation 509 comprises an activation class for users, such as 
-subscription". The class User 402 has a many*to-many relationship with the class Agt?vatjffn 
509 using the cross-link class Activation to User Link 510. Similariy, the class User Qyoup 403 
has a many to-many relationship with the class Activation 509 using the cross-link class Activa- 
5 ^mn tnlUgf Group 51 L 

In a preferred embodiment, the system 200 also provides that some or all attach- 
ments are stored in a central location that is not accessible by other applications running under 
control of the same operating system (unless those other applications are launched from withm 
10 the qrstem 200). 

BtiiLDiNG AND EomNG A Data Model 

Figure 6 shows a flow diagram of a process for biulding and editing a data model of 
the user's object database. 
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25 



At a flow point 600, the usct 201 desires to build or edit the user database model 

230. 

In a prcfexred embodiment, the system 200 provides a facility for atomic transac- 
tions, using a '^transaction begin" command and a **transaction end" command, to be invoked by the 
user 201. When the user 201 invokes the *iransacti<Mi begin" command, all changes to the user da- 
tabase model 230 or to the relational database 250 arc collected, and committed in one atomic op- 
eration when the user 201 invokes the ^^transaction end** conunand. This feature allows the user 
201 to protect the user database model 230 and the relational database 250 against partial changes. 

Although this flow diagram is described with regard to an order in which the system 
200 examines the user's commands, in acmal practice the user 201 specifies the order in which 
commands are to be executed, and need not follow the oider indicated in this flow diagram. 
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Atastq>610,thesystOTdeteiiTiinesiftbeuser201 chooses to build, edit or delete a 
class lOL If so, the system 200 proceeds to the step 612. Othmvise« the system 200 proceeds to 
the step 620. 

At the step 612, the user 201 has chosen to build, edit or delete a class lOL If the 
user 201 chooses to build a new class 101, the system 200 proceeds to the step 614. If the user 201 
chooses to edit an existing class lOU the system 200 proceeds to the step 616. If the tiser 201 
chooses to delete an existing class 101, the system 200 proceeds to the step 618. 

At the step 614, the system 200 creates a new object of class Class 301 in the meta* 
model 220. The system 200 provides a capability for the user 201 to select values for the prop- 
erties 102 of the new object of class Class 301 which has just been created. For some of these 
properties, sudi as '"Ciass DB Name*", the system 200 generates a de&ult value, but for others, it 
requires that the user 201 supply a value. The system 200 then retunos to the step 610. 

At the step 616, the user 201 selects an object of class Class 301 in the meta-model 
220, and proceeds to edit thai object The system 200 receives editing commands and changes 
the values for the properties 1 02 of the object The system 200 then returns to the step 61 0. 

At the step 61 8, the user 201 selects an object of class Class 301 in the meta-model 
220, and proceeds to delete that object. The system 200 removes the object from the meta-model 
220, and implements any delete rules, such as deleting the objects of class Class Property 303 
which relate to that object of class Class 301 . The system then returns to the step 610. 

At the step 620, the system detenmines if the user 201 chooses to build, edit or de- 
lete a class property 102. If so, the system 200 proceeds to the step 622. Otherwise, the system 200 
proceeds to the step 630. 

At the step 622, the user 201 has chosen to build, edit or delete a class properly 102. 
If the user 201 chooses to build a new class property 102. the system 200 proceeds to the step 624. 
If the user 201 chooses to edit an existing class propert>' 102. the system 200 proceeds to the step 
626. If the user 201 chooses to delete an existing class property 102. the system 200 proceeds to the 
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Step 628. (Of course, as class properties 102 are related to classes 101, any of these actions has the 
effect of editing a class 101 .) 

At the step 624, the system 200 creates a new object of class Class Property 303 in 
the meta-model 220. The system 200 provides a capability for the user 201 to select values for 
the properties 102 of the new object of class Class Property 303 which has just been created. For 
some of these properties, such as "Class Property DB Name", the system 200 generates a default 
vahie, but for othere, it requires that the user 201 siwly a value- The system 200 then returns to the 
step 610. 

At the step 626, the user 201 selects an object of class Class Property 303 in the 
meta-model 220, and proceeds to edit that object The system 200 receives editing commands 
and changes the values for the properties 102 of the object The system 200 then returns to the 
step 610. 

At the step 628, the user 201 selects an object of class qpss Property 303 in Ae 
meta-model 220, and proceeds to delete that olqect. The system 200 removes the object from the 
meta-model 220, and implements any delete rules. The system then returns to the step 610. 

At the step 630. the system deteraunes if the us» 201 chooses to build, edit or de- 
lete a relationship 103 between classes 101. If so, the system 200 proceeds to the step 632. Other- 
wise, the system 200 proceeds to the flow poirt 640. 

At the step 632, the user 201 has chosen to build, edit or delete a relationship 103 
25 between classes 101. If the user 201 chooses to build a new relationship 103 between classes 101, 
the system 200 proceeds to the step 634. If the user 201 chooses to edit an existing relationship 103 
between classes 101. the system 200 proceeds to the step 636. If the user 201 chooses to delete an 
existing relationship 103 between classes 101, the system 200 proceeds to the step 638. (Of course, 
as relationships 103 between classes 101 comprise pointer class properties and are related to classes 
30 101, any of these actions has the effect of editing a class 101.) 
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At the step 634, tfie system 200 creates a new object of class Pointer Class Property 
304 in the meta-model 220. The system 200 provides a capability for the user 201 to select val- 
ues for the properties 102 of the new object of class Pointer Class Propotv 304 vsUch has jmt 
been created For some of these properties, such as "Pointer Class Property DB Name", the systan 
5 200 generates a default value, but for others, it requires thai the user 201 supply a value. The sys- 
tem 200 then returns to the step 61 0. 

At the step 636, the user 201 selects an object of class Pointer Class Property 304 in 
the meta-model 220, and proceeds to edit that object The system 200 receives editing coin- 
10 mands and changes the values for the properties 102 of the object The system 200 then returns 
to the step 610. 

At the step 638, the user 201 selects an object of class Pointer Class Property 304 in 
the meu-model 220, and proceeds to delete that object The system 200 removes the object from 
1 5 the meta-model 220, and implements any delete rules. The system then returns to the step 610. 

At the llovy point 640, the user 201 does not desire to build, edit or delete any 
further objects in the meta-model 220, and the process is complete. 

20 Compilation and Translation Process 

Figure 7 shows a flow diagram of a process for compilation and translation be- 
tween object-oriented and relational database structures. 

At a flow point 700, the user 201 desires to translate the user's object database 
2S 1 00 into the corresponding relational database 203. 

At a step 710, the user 201, having completed editing the user model 230. triggers 
the translation process. 
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At a step 720, the system 200 selects a class 101 in the user's object database 100. 
If there arc no more classes 101 to select in the user's object database 100, the syston 200 pro- 
ceeds with Ac step 740. 

At a step 730, the system 200 creates a table in the correq>onding relational data- 
base 203 to correspond to the selected class 101. 

At a step 740, the system 200 creates a set of specified columns in the table. 
These specified columns include a column for a unique identifier ("UID") for each object, a col- 
umn for the **class identifier" for each object, and a column for the "object type" for each object. 

When an object is populated into the corresponding relational database 203, the 
system 200 will create a row in the table corresponding to the object's class 101 , and in each ta- 
ble corresponding to a base class 101 for the object's class 101. Thus, each object will corre- 
spond to one row in each table corresponding to each class 101 which is a base class 101 for the 
object's class 101. 

The fust column in each table is for the UID for each object. Thus, in each table 
in which a row is created for the object, the first column corresponds to the UID for the object. 
This column is preferably selected to be the first, leftmost, column because many relational data- 
base engines 240 are optimized to perfom indexed searches on that first column. 

Another column in each table is for the "class identifier" for each object. Because 
an object corresponds to a row in the table for its class 101 and in each table for a base class 101 
for its class 101, it is efficient to record an identifier of what class 101 each object is, in each ta- 
ble for vrtiich a row for that object is stored. 

Another column in each table is for the "object type" for each object. Like the 
searchable property 102 "Class Type^' in the class Qag 301, the "object type- column indicates 
whether this particular object (as opposed to an entire class) is part of the meta-model, or is an ob- 
ject created by the tiser. 
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At a stq> 750, the system 200 creates a column in the table for a value for a 
searchable property 102 for the class 101. If the searchable property 102 has a built-in datatype, 
the colunm holds the actual value for that built-in datatype. Otherwise, if the searchable property 

102 has a user-defined datatype, the colunm holds the UID for the object corresponding to the 
S value for that user-defined datatype. 

At a step 760, the system 200 creates a column in the table for each relationship 

103 between the class 101 and a related class 101. In the column for this relationship 103, the 
system 200 places the UID of the object in the related class 101 which is related to the object in 

10 the class 101 for this table. If the relationship 103 is many-to-one, the system creates multiple 
lecords in the table for the same object, each with the UID of a different object in the related 
class 101. 

At a flow point 770, the compilation and translation process is complete. 

15 

Sample Target Relational Database 

Figure 8 shows a data model diagram of a user relational database corresponding to 
the sample user's object database of figure 1 . 

20 As described with regard to figure 7, the user relational database 230 corresponding 

to the user's object database 100 comprises a set of relational tables 800, each corresponding to a 
class 101 . Accordingly, in the example of figure 1 , the system 200 creates a table 800 comtx>nent a 
table 800 analog component a table 800 memory, a table 800 dynamic memory, a table 800 static 
memory, a table 800 manufacturer , a table 800 domestic manufacturer , and a table 800 foreign 

25 manufacturer . Each such table 800 comprises a set of colunuis 8 1 0 and a set of rows 820. 

The system 200 creates, for each table 800, a column 810 **Object ID'' for the UID 
# 

of the object, and assures that objects added to each table 800 for derived classes 101 are also added 
to tables 800 for the base classes 101, with corresponding UIDs. For example, each row 820 added 
30 to the table 800 static memory corresponds to a row 820 added to the table 800 memory and corre- 
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spends to a row 820 added to the table 800 component and the UIDs are identical in the column 
810 **Object ID" for these three rows 820. 

The system 200 also creates for the table 800 component a column 810 "name" for 
the name of the component, for the table 800 memoiv a column 810 "size" for the size of the com- 
ponent, for the table 800 manufacturer a column 810 "name'' for the name of the manufacdiicr and 
a column 810 "city" for its city, and for the table 800 fnrei^ manufacnirer a column 810 "country" 
for the countiy of the foreign manufacturer. 

The system 200 also creates for the table 800 component a column 810 
'^manufecturer" for the UID of the manufacnirer, identical to the UID of a row 820 in the table 800 
manufacturer, thus establishing the relationship 103 between objects of the class 101 compopeyH 
and objects of the class 101 manufacnirer. 

Cascade Searching and Search Translation 



Figure 9 shows a flow diagram of a process for cascade searehing of an object 
database and search translation between object-oriented and relational database structures. 

At a flow point 900, the user 201 desires to perform a cascade search of the user's 
object database 100, 

flpecifving f He Cascade Search 

At a step 910, the user 201 specifies the cascade search request i*.. the classes to 
be cascaded and the properties to be searched in each class. The user interface 210 receives the 
information fiom the user 201 . To perform this step 910, the system 200 performs the steps 91 1 
through 916 inclusive. 

At a step 91 1, the user interface 210 obtains a list of classes 101 in the user data- 
base model 230 from the mcta-mode! 220, and presents the list of classes 101 to the user 201 for 
selection. 
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In an example cascade search using die example user's object database 100 in fig- 
ure 1, the system 200 would present the list of classes 101 available in the user database model 
230. 

5 

At a step 912, the user 201 selects a class 101. The user interface 210 obtains a 
list of related classes 101 (i.e., classes 101 coupled to the selected class 101 by a relationship 
103) in the user database model 230 from the meta-model 220, and their derived classes 101. 
The user interface 210 presents the list of related classes 101 and their derived classes 101 to the 
10 user 201 for selection. 

In this example cascade search, the user could select the class 101 static memory . 
The class 101 static memory inherits all the relationships 103 of its parent class 101 memory and 
all the relationships 103 of its grandparent class 101 component vMch includes a relaticmship 
15 103 with the class 101 manufacturer . 

At a step 913, the user 201 may select a related class 101 or a class 101 derived 
from a related class 101. So long as the user 201 continues to select related classes 101 or their 
derived classes 101, the system 200 continues with the step 912. When the user 201 declines to 
20 select any further related classes 101 or their derived classes 101, the system continues with the 
step 914. 

In this example cascade search, the user 201 could select the class 101 foreipn 
manufacturer, which is a class 101 derived from the related class 101 manufacturer . 

25 

At a step 914, for each class 101 selected by the user 201, the user interface 210 
obtains a list of searchable properties (and any restrictions on their values) in the user database 
model 230 from the meia-model 220, and presents the list of searchable properties to the user 
201 for selection. 

30 



41 



WO96O4350 PCr/US96«5678 

In this example cascade search, the system 200 would present the searchable 
properties 102 -name" and "size" for the class 101 static memory, and would present the 
searchable properties 102 ""name** and "country*' for the class foreign manufacturer. 

At a step 915, ±c user 201 selects at least one searchable property 102 of the se- 
lected classes 101 , may specify restrictions on their values, and may continue to select searchable 
properties 102 of the selected classes 101. So long as the user 201 sontinues to select searchable 
properties 102, the system 200 continues with the step 914. When the user 201 declines to select 
any further searchable properties 102, the system continues with the step 916. 

In this example cascade search, the user 201 could select the searchable property 
102 '"name** for the class 101 static memoiv to be presented, and selected the searchable property 
102 *'countiy" for the class 101 foreign manufacturer to be searched, and require that the latter 
must equal the text string 'France'. 

In a pieferred embodiment, the steps 914 and 915 may proceed in parallel with the 
steps 912 and 913. When the user 201 selects a class 101, the system 200 presents the searchable 
properties 102 in that class 101 for selection, and also presents the related classes 101 (and de- 
rived classes 101) for selection. Instead of responding to a prompt, the user 201 then uses a 
pointing device to select either a related class 101 (or derived class 101) or a searchable property 
102, or selects a command to trigger the cascade search (in the step 916). 

At a step 916, the user 201 indicates that the cascade search has been fully speci- 
fied, and triggers the search. The system 200 provides a technique for the user 201 to record the 
specification of a cascade search, to recall the specification of a previously recorded cascade 
search, to edit the specification of a cascade search to create a new cascade search, and to apply a 
previously recorded cascade search to the current relational database 250. 

In this example cascade search, the user 201 has requested a cascade search for 
'the names of all static memories made by a manufacturer from France*. 



Rinlding the Query Model 
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At a step 920, the system 200 parses die cascade search request and builds the 
query model 260« To perform this step 920^ the system 200 performs the steps 921 through 922 

inclusive. 

5 At a step 921 , the system 200 builds a configuration object 991 for the initial class 

101 selected by the user 201 to be searched. Each such configuration object 991 represents a. 
single class 101 selected by the user 201, and comprises a first list of searchable properties 102 to 
be searched, a second list of searchable properdes 102 to be displayed in the query result 251, 
and a third list of classes 101 starting with the initial class 101 selected by the user 201, and con- 
1 0 tinning with each related class 101 selected by the user 201 . 

At a step 922, the system 200 biiilds a configuration object 991 for each additional 
class 101 selected by the user 201 to be searched, and links each such additional configuration 
object 991 to the configuration object 991 for the initial class 101 selected by the user 201 to be 
IS searched. 

Rinldinpthe SQL OueiV 

At a step 930, the system 200 bwlds the SQL query 261 in response to the query 
model 260. To perform this step 930, the system performs the steps 93 1 through 936 inclusive. 

20 

At a step 931, the system 200 re-links the configuration object 991 into a list of 
query model objects 992. Each query model object 992 specifies a single search field or a single 
result field of the cascade search. 

25 At a step 932, the system 200 performs table alias analysis for the query model 

260. 

To perfonn this step 932, the system 200 examines the list of query model objects 
992 and determines if translation of the query model 260 into SQL commands 261 would other- 
30 wise cause any table to be joined with itself, e.g., if two or more different columns of the same 
table appear in the query model 260. If so, the System 200 generates a unique name for an Ora- 
cle ""alias" for each instance of that ubie after the first, creates an alias record 993 for each such 
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alias, and attaches the alias record 993 to the list of query model objects 992. The alias record 
993 indicates that the alias should be specified and the table referred to using the alias in the SQL 
commands 261 to be generated. 

At a step 933, the system 200 performs join analysis for the query model 260. 

To perform this step 933, the system 200 examines the list of query model objects 
992 and determines if translation of the query model 260 into SQL conrmiands 261 would other- 
wise cause any duplicate join conditions to be specified, e.g., if a first and second table are joined 
twice using the same join condition. If so, the system 200 selects a single one of the join condi- 
tions to be applied, creates a join record 994 for each such join condition, and attaches the join 
record 994 to the list of query model objects 992. The join record 994 indicates that the single 
join condition shoiild be specified, and that duplicate join conditions should be omitted, in the 
SQL commands 261 to be generated. 

At a stq) 934, the system 200 performs search condition analysis for the query 

model 260. 

To perform this step 934, the system 200 examines the list of query model objects 
992 for each of the search conditions shown in table 9-1, creates a condition record 995 for each 
search condition, and attaches the condition record 995 to the list of query model objects 992. 

Table 9-1 

o Comparison of a searchable property with a numeric value, represented in the SQL com- 
mands using a "WHERF* clause and a logical comparison of a colunm in the relational 
database 250 with that nimieric value. 

o Comparison of a searchable property with a text string, represented in the SQL com- 
mands using a "WHERE'' clause and a logical comparison of a column in the relational 
database 250 with that text string. If the text string to be compared comprises 
"wildcards'* (e.g., special characters to indicate matching with one or more arbitrary char- 
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acters), the comparison is represented in the SQL commands using the Oracle ''LIKF* 
statement. If the text string to be compared is case-insensitive, the comparison is repre- 
sented in the SQL commands using an Oracle statement for forcing case to upper case. 
Other string operations arc converted to appropriate Oracle statements using a conversion 
5 table. 



10 



Comparison of a searchable property using a different unit of measurement, represented 
in the SQL commands using the appropriate conversion function for the source and target 
units of measurement, as recorded in the meta-model 220. 

Multiple comparisons of multiple searchable properties, or other boolean operations on 
comparisons, represented in the SQL commands using boolean lo^cal operators such as 
"AND", "OR**, and **NOT. 



IS o Comparison of a searchable property with a group of numeric or text string values, or a 
range of numeric values, represented in the SQL commands using a plurality of compari- 
sons of the same searchable property with different numeric or text string values. 

In a preferred embodiment, when a cascade search relates to a searchable property 
20 102 having a unit of measurement, the system 200 examines the units of measurement for the 
searchable property 102 and for the value it is being compared against, and if they are not the 
same, adjusts the SQL commands 261 to account for different tmits of measurement. 



To make this adjustment, the system 200 examines the object of class Class Prop- 
25 ertx 303 for the searchable property 1 02, and searches the meta-model 200 for the object of class 
Unit of Measurement 310 associated (as. a storage unit of measurement) with that object of class 
Class Property 303. The system 200 then examines the query model 260, determines the unit of 
measurement for the cascade search, and searches the meta-model 200 for the object of class 
Unit of Measurement 310 associated with that unit of measurement. The system 200 then 
30 searches the meui-model 200 for the object of class Unit Conversion Formula 31 1 which con- 
verts the fu5t unit of measurement to the second, and inserts a call to that unit conversion for- 
mula into the SQL commands 261 . 
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At a Step 935, the system 200 perfonns optimization analysis for the quay nKxiel 

260. 

To perform this step 935, the system 200 examines the query model 260 for each 
of the optimization conditions shown in table 9-2, and modifies the query model 260 to generate 
SQL commands 261 according to the optimization techniques shown therein. 

Table 9-2 

o Row Selectivity. A value for "Row Selectivity" is computed by the system for each 
searchable property, according to the following formula: 

# of distinct values 
Row Selectivity » -— ■ — 



# of objects mth non-null values 

Row Selectivity is multiplied by 100 to normalize it as a percentage, and used to deter- 
mine if the column modeling that searchable property steuld be indexed. If the Row Se- 
\ce6vity of a column is more than 70%, the column is almost always indexed; if the Row 
Selectivity of a column is less than 30%, the column is almost never indexed. 

Avoiding Soit/Merge. Using multiple indexed columns in a WHERE clause causes the 
Oracle RDBMS to perform a sort/merge operatim. As sort/merge operations take sub- 
stantial time, the system 200 attempts to replace such constructs with WHERE clauses 
wluch use only one indexed column. 

To cause an indexed column to be treated by the Oracle RDBMS as non-indexed. the 
value to be searched is changed ftom the raw column value, table-column, to a computed 
value, table.column+0 (for numeric values) or table.columnll" (for text string values). 
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Otherwise, viiere a column is indexed, the system attempts to write SQL commands to 
require the Oracle RDBMS to treat that column as indexed. When a iunction or arithme- 
tic operation is ^plied to a column value, the Oracle RDBMS does not treat tfie column 
as being indexed. Accordingly, the system prefers to avoid these constructs. For exam- 
ple. "WHERE frequency = 3000" is preferred to "WHERE frequency/3 = 1000". 

Array Fetching. When large numbers of rows are to be selected fit>m a table, the system 
attempts to fetch those rows into an array, for faster retrieval. 

Search Condition Ranking. When the system prefers a certain search condition order, for 
faster retrieval, it may alter the nature of the search conditions to place them in formats 
which cause the Oracle RDBMS to assign search priority in the order the system prefers. 

Table Name Sequence, In a FROM clause, the "driving" table, i.e., the table which is an 
intersection table, or the table with the smaller number of records if there is no intersec- 
tion table, is placed at the end of a FROM clause. Other tables in the FROM clause are 
ordered similarly. 

Condition Predicate Sequence. In a WHERE clause, the "driving" condition predicate, 
i.e., the most efficient condition predicate that will return the fewest records, is placed at 
the beginning of a WHERE clause. Other condition predicates are ordered similarly. 

Booster Engines. In a WHERE clause, if die selected condition predicate would cause 
the Oracle RDBMS to perfonn a non-indexed search, a secondary condition predicate is 
added to first perfonn an indexed search and reduce the number of records to be searched. 

For example, the SQL command "SELECT . . . FROM part WHERE UP- 
PER(part.partnumber) « UPPER(*DM54ALS1 HAJT would perfonn a non-indexed 
search because each pan.pannumber would have to be converted to upper case. (This is 
simply a case-insensitive search on pan.partnumber.) Instead^ the system prefers the SQL 
command "SELECT . . . FROM part WHERE UPPER(pan.partnumber) » UP- 
PERCDM54ALS114AJ') AND (pan.partnumber LIKE 'D%54%1 14%T. where all al- 
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phabetic characters except the first have been replaced witii Oracle wildcards in the 
search text The LIKE clause is performed as an indexed search and is thus mudb faster, 
and also reduces the number of records which must be manipulated and chedced for the 
case-insensitive comparisoa 

Table Aliases. The system prefers to use table aliases and to prefix column names with 
their aliases whenever there is more than one table specified in the FROM clause of a 
SELECT statement, as this provides for faster parsing time. 

Preferred Constructs. Certain SQL statements are preferred for efiBciency, even though 
their alternatives are functionally equivalent For example, in general, the NOT EXISTS 
construct is preferred to the NOT IN construct the EXISTS construct is preferred to the 
DISTINCT construct the WHERE construtt is preferred to the HAVING consButt, and 
table joins are preferred to sub^ueries. 

NOT and OR Operators. The system prefers to avoid WHERE clauses which use a ne- 
gated operator, such as NOT EQUALS, because the Oracle RDBMS performs a non- 
indexed table scan in these case. 

20 Similarly, in a WHERE clause which has multiple index predicates separated by lo^cal 

OR. the most specific index piedicate is placed at the beginning of the WHERE clause. 

If the logical OR clause refas to two indexed columns, the system inefers to use the 
UNION construct to select all rows which satisfy either condition predicate. 
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30 



The SQL commands 261 are dynamically generated in response to the <juery 
model 260 and the list of query model objects 992, which are themselves generated in response 
to the cascade search specified by the user 201. Each cascade search is potendally quite differ- 
ent so the system 200 first provides for generating SQL commands 261 to pcrfoim the cascade 
search function, and then provides for optimizing those SQL commands 261 so as to peiform the 
search in an efficient manner. 
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Those skilled in the art will recognize, after perusal of this application, that other 
and further optimizations of SQL commands 261 generated by the system 200 are possible, that 
such other and further optimizations are within the scope and spirit of the invention, and that 
such other and further optiihizations would not require either invention or undue experimenta- 
S tion. 

At a step 936, the system 200 examines the query model 260, the list of query 
model objects 992, the alias records 993, the join records 994, and the condition records 99S, and 
in response, generates SQL commands 261 using the fonn shown in table 9-3. 

10 

Table 9-3 

"SELECT <result> FROM <tables and aliases> 
WHERE <JOIN of tables> 
15 AND <condition^" 

The fonn in table 9-3 includes a <results> section for specifying the form of the 
query results 251, a <tables and aliases> section for specifying the tables in the relational data- 
base 250 to be searched, a <JOIN of tables> section for specifying bow ttu! tables to be searched 
20 arc joined, and a <conditions> section for specifying additional conditions to be met by those re- 
cords to be retrieved. There may also be additional SQL stateroenu after the <conditions> sec- 
tion, such as a section for the SQL "GROUP BY**, "ORDER BY** or other statements. 

biformation regarding the form of the query results 25 1 to be presented to the user 
25 201 is inserted in the <result> section of the SQL commands 261, In a preferred embodiment, 
the information regarding the form of the query results 251 comprises a sequence of columns to 
be selected (using the SQL "SELECT* statement) from tables in the relational database 250. The 
sequence of columns to be selected comprises those columns requested by the user 201 when 
specifying the cascade search. 

30 

In this example cascade search, the system 200 would generate SQL commands 
261 with a result section specifying the class 101 static memory and the searchable propert>' 102 

49 



10 



PCTAIS96nSC78 

WO 96^50 

"name". The SQL commands 261 would thus begin with a statement such as "SELECT 
stalic_memoiyj»aine". 

Infonnation regarding the tables (and aliases of tables) in the relational database 
250 to select data fiom is insetted in the <tables and aliases> section of the SQL commands 261 . 
In a prefcned embodiment, the infonnation regarding the tables and aUases comprises a sequence . 
of tables and aliases of tables to be joined fiom the relational database 250 into a single joint ta- 
ble to be seardicd. The choice and order of the tables and aliases to be joined is retrieved fiom 
the alias records 992 and the join records 993 created by flie system 200. 

In this example cascade seanA, the system 200 would generate SQL commands 
261 with a result section specifying the class 101 static memory and the searchable property 102 
"name". The SQL commands 261 would thus continue with a statement such as "FROM 
sutic_rocmoiy, roemoiy, component, foreign.manufacturcr, manufacturer". 

Information regarding flie conditions to be met is mserted into the <com«tions> 
section of the SQL commands 261. In a preferred embodiment, the information regarding the 
conditions to be met comprises a sequence of logical operators (using tiie SQL "WHERF* state- 
ment, and using the SQL "AND" statement where ti»ere are multiple conditions) which roust be 
raet by records selected from tiie relational database 250. The choice and order of tiie conditions 
to be met is retrieved fiom die condition records 994 created by tiie system 200, 

In titis example cascade search, tiie system 200 would generate SQL commands 
261 witii a condition section specifying tiie logical conditions required by tiie user 201, by refer- 
25 ence to the searchable properties 102 of die specified classes 101. The SQL commands 261 
would tiius continue witii a statement such as "WHERE (manufacturer-countiy = Trance')". 

In addition to logical conditions imposed by tiie user, tiie <conditions> section 
must impose any logical requirements for JOIN of ubies 800. There are two types of JOIN, 
those required by inheritance relationships between classes 101. and tiiose required by data- 
model relationships 103 between classes 101. 
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As noted with regard to figure 8» inheritance relationsfaips are modeled by pro- 
viding a colunm 810 ''Object ID*" in each table 800; ^en an object of a derived class 101 is cre- 
ated in the relational database 250, a row 820 is provided in both the base class 101 and the de- 
rived class 101, with the same object UID for that object for both tables 800. Thus, inheritance 
5 relationships are modeled in the SQL commands 261 by a JOIN statement relating to the identity 
of the two object UIDs, and by the parent/child relationship recorded in the meta-model 220. 

In this example cascade search, the system 200 would generate SQL commands 
261 with a condition section specifying the inheritance relationship between the class 101 static 
10 memory, its parent class 101 memory, and its grandparent class 101 comtx>nent . The SQL com- 
mands 261 would thus continue with a statement such as ''AND (static_memory.objectID 
memory.objectID) AND (memoiy.objectED « component.objectID)". Similarly, the SQL com- 
mands 261 would also continue with a statement such as "AND (manufacturer.objectlD for- 
e]gn_nianufacturer.objectID). 

15 

In practice, because the user 201 has not made reference to any searchable prop- 
erties 102 of the class 101 memory, there is no need to explicitly require use of the table 800 
memory, and there is thus no need to require matching object UIDs in that table 800. The system 
200 would thus omit the inheritance JOIN for this table. 

20 

As noted with regard to figure 8, data-model relationships 103 between source 
and target classes 101 are modeled by providing a column 810 in the source table 800 pomting to 
an object in the target table 800, i.e., having the object UID of a row 820 in the target table 800. 
Thus, data-model relationships 103 are also modeled in the SQL commands 261 by a JOIN 
25 statement relating to the identity of a pointer with an object UID, and by the data-model relation- 
ship recorded in the meta-model 220. 

In this example cascade search, the system 200 would generate SQL commands 
261 with a condition section specifying the data-model relationship 103 between the class 101 
30 component and the class 101 manufacturer . The SQL commands 261 would thus continue with a 
statement such as '*AND (component.manufacturerID = manufacturerobjectlD)*'. 
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Thus, in this example cascade search, the SQL commands 261 would be like that 
shown in table 9-4. 

Table 9-4 

SELECT SM.namc 
FROM component C, 

static^memory SM, 

maniifacturerM, 

foretgn_manufacturer FM 
WHERE (FM.country = Trance') 

AND (M.objectID « FM.objcctID) 

AND (C jnannfiaiCtUTerlD ~ M.objectID) 

AND (SM.objectID = CobjcctlD). 

Note that these SQL commands 261 arc genemted by the system 200 in response 
to the user*s specification of the cascade search, as applied to the user database model 230, and 
the translation of the user database model 230 into the user relational database 231. The system 
200 provides the dynamic translation of the cascade search, seamlessly translating between the 
object-oriented model used by the cascade search and the user database model 230, on the one 
hand, and the relational model used by the user relational database 231 and the SQL commands 
261, on the other hand. 

At a step 940, the system 200 transmits the SQL query 261 to the relational data- 
base engine 220. 

At a step 950. the relational database engine 220 applies the SQL queiy 261 to the 
corresponding relational database 203. creates the results table 262, and transmits the results ta- 
ble 262 to the user interface 210. 



At a step 960, the user interface 210 presents the information in the results table 
262 to the user 201. 
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The results uble 262 is preferably presented to the user 201 like a relational table, 
showing objects found by the cascade search and each searchable property 102 the user 201 se* 
lected for display. 

5 

In a preferred embodiment, the user interface 210 also provides the user 201 with • 
the option to display objects found by the cascade search and their searchable properties 102 in a 
foixn for comparison, e.g., side by side in a spreadsheet format In the comparison format, the 
user may view searchable properties 102 of the objects, edit searchable properties 102 for the 
10 objects, either individiially or for multiple objects at once, and perform comparisons between 
objects, such as displaying those searchable properties 102 whidi differ from a selected object • 

At a flow point 970, the cascade search is complete. 
1 S Altematiye Embodiments 

Although preferred embodiments are disclosed herein, many variations are possi- 
ble which remain within the concept, scope, and spirit of the invention, and these variations 
would become clear to those skilled in the an after perusal of this application. 
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Claims 

I claim: 

1 . A system, comprising 

means for receiving a description of a uscr^s object database, said uscr*s object 
5 database having a set of classes and a set of relationships between pairs of said classes; 

means for creating a model of said user's object database in response to said de- 
scription; 

means for creating a relational database in response to said model said relational 
database having a set of tables, keys for said tables, and relationships between pairs of said tables 
1 0 implementing said classes, objects and relationships of said user's object database; 

means for receiving a set of data objects for said user's object database; 

means for translating said set of data objects for said user's object database into a 
set of records for said relational database, and for inserting said set of records into said relational 
database; 

J 5 means for receiving updates to said description of a user's object database; 

means for updating said model in response to said updates; 
means for updating said relational database in response to said means for updating 

said model; and 

means for updating said set of records for said relational database in response to 
20 said means for updating said relational database. 

2. A system as in claim 1 , comprising 

a relational database server, said server comprising means for accepting a set of 

relational database commands; 
25 wherein said means for translating and for inserting comprises means for gener- 

ating a set of relational databiase commands. 

3. A system as in claim I , wherein said means for inserting comprises 
means for generating records for said tables; 
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means for generating values for said keys for said records; and 
means for causing said values for said keys for said records to correspond to said 
relationships between pairs of tables. 

5 4. A system as in claim U herein said means for inserting comprises means 

for maintaining said tables, keys for said tables, and said relationships between pairs of tables 
while inserting said set of records into said relational database. 

5. A sj^stem, comprising 

10 means for receiving a description of a user's object database, said user^s object 

<jat?bi»yg having a set of classes and a set of relationships between pairs of said classes; 

means for creating a model of said user's object database in response to said de- 
scriptiottt said model comprising an object database having 
a first class of objects, 

15 an object of said first class cotresponding to each said one class in said 

user's object database, 

a second class of objects, and 

an object of said second class corresponding to each said one relationship 
in said user's object database; and 
20 means for creating a relational database in response to said model, said relational 

database having a set of tables, keys for said tables, and relationships between pairs of said tables 
implementing said classes, objects and relationships of said user's object database. 

6. A system as in claim S, comprising 

25 a relational database server, said server comprising means for accepting a set of 

relational database commands; 

wherein said means for creating a relational database comprises means for gener- 
ating a set of relational database commands. 

30 7. A system as in claim 5, wherein said server comprises means for accepting 

a set of relational database commands from a second source of said commands. 
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8. A system, comprising 

means for receiving a description of a user's object database, said user's object 
database having a set of classes and a set of relationships between pairs of said classes, and for 
receiving updates to said description; 

means for creating a model of said user's object database in response to said de- 
scription, and for updating said model in response to said updates; and 

means for creating a relational database in response to said model, said relational 
database having a set of tables, keys for said tables, and relationships between pairs of said tables 
implementing said classes, objects and relationships of said user's object database, and for up- 
dating said relational database in response to said means for.updating said model. 

9. A system as in claim 8, comprising means for receiving a triggering signal, 
wherein said means for updating said relational database operates in response to said triggering 
signal. 

10. A system, comprising 

means for receiving a description of a user's object database, said user's object 
database having a set of classes and a set of relationships between pairs of said classes; 

means for creating a model of said user's object database in response to said de- 
scription; 

means for creating a relational database in response to said model, said relational 
database having a set of tables, keys for said tables, and relationships between pairs of said tables 
implementing said classes, objects and relationdiips of said user's object database; 

means for receiving a description of a query against said user's object database; 

and 

means for translating said query into a relational database query suitable for ^pli- 
cation to said relational database. 

11. A system as in claim 1 0, comprising 

means for e^plying said relational database query to said relational database: and 
means for presenting an output of said means for applying. 
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12. A method for searching a database* said database having a plurality of 
classes, at least one searchable property associated with one of said classes, and at least one data- 
model relationship between a pair of said classes, said method, comprising the steps of 

specifying a query model, said query model comprising a iirst class and at least 
S one searchable property associated with said first class, a second class related to said first class 
by a first said data-model relationship, and at least one searchable property for said second class; 
translating said query model into a set of relational database commands; 
applying said relational database commands to a relational database and retrieving 
a query result in response thereto; and 
10 displaying said queiy result 

13. A method as in claim 12, 

wherein said relational database comprises a set of relational tables; and 

wherein said step of translating comprises the steps of 
IS identifying a first relational table associated with said first class and a second le* 

lational table associated with said second class; 

first generating at least one database command to join said first relational table 
and said second relational table to produce a relational join, responsive to a data-model relation- 
ship between.said first class and said second class; 
20 identifying a first coiunm associated with said first searchable property; and 

second generating at least one database command to test records of said relational 
join in said colimin, responsive to a test for said searchable property. 

14. A method as in claim 12, 

25 wherein said relational database comprises a set of relational tables; and 

wherein said step of translating comprises the steps of 

identifying a first relational table associated with said first class and a second re- 
lational table associated with a base class of said first class; 

first genei^tiiig at least one database command to join said first relational table 
30 and said second relational table to produce a relationahjoin, responsive to an inheritance relation- 
ship between said first class and said base class of said first class; 

identifying a first column associated with said first searchable property; and 
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second generating at least one database conunand to test records of said relational 
join in said column, responsive to a test for said searchable property. 

15. A metliod as in claim 12, wherein said step of translating comprises 
5 generating a set of database commands to perform a query represented by said 

query model; and 

optimizing said set of database commands to perfonn a faster query of said tela* 
tional database. 

10 16. A method for searching a database, said database having a plurality of 

classes, at least one searchable property associated with one of said classes, and at least one data- 
model relationship between a pair of said classes, said method, comprising the steps of 
presenting a first list of said classes; 
receiving a selection of a first class from said first list; 
1 s receiving a selection of a searchable property associated with said first class; 

presenting a second list of said classes, said second list comprismg classes having 
a base class related to said first class by a said data*model relationship; 

receiving a selection of a second class firom said second list; 
receiving a selection of a searchable property associated with said second class; 
20 generating a set of relational database commands, said set of relational database 

commands being effective to present a query to a relational database, said query having the se- 
mantic effect of said selections of said first class, said first searchable property, said second class, 
and said second searchable properly; 

applying said set of relational database commands to said relational database and 
25 retrieidng a query result in response thereto; and 
displaying said query result. 

17. A method as in claim 16, wherein said set of relational database com- 
mands comprise at least one table join responsive to a data-model relationship in said database. 
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18. A method as in claim 16, wherein said set of relational database com- 
mands comprise at least one table join responsive to an inheritance relationship in said database. 
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19. A method as in claim 16, wherein 

said database comprises at least one searchable property associated with a first 
unit of measurement; and 

said set of relational database commands comprise at least one comparison re- 
sponsive to a conversion of said first imit of measurement to a second unit of measurement 

20. A method as in claim 1 6, wherein said step of generating is responsive to a 
meta-model of said database, said meta-model comprising a first class of objects representative 
of classes of said database and a second class of objects representative of searchable properties of 
said database. 



59 



wo 96/34350 



1/9 



PCTA}S96;05678 



100 



I 



101 

I— 

COMPONENT 
NAME., 



103 



•102 



MANUFR 
NAME 
CITY 



ANALOG 
COMPONENT 



MEMORY 
SIZE 



DOMESTIC 



FOREIGN 
COUNTRY 



DYNAMIC 
MEMORY 



STATIC 
MEMORY 



FIG. 1 



SUBSmUTE SHEET tRULf 26) 



wo 94^50 



PCT/US96A)5678 





SUBSnrniE SHEET (RULE 26) 



wo 96/34350 



PCTAJS96AHW78 



<(05O 
UJ u-o 



3/9 



CO 

<9 



lA 
- ^ 

CO 



toil 
"is 



CO 

CA 
3 



• 'T- CO 

" s 

3 



f 



CO 
CO 



5 

O 



< 

HI 



O 

3 



o 
cc 

CL 

€0 
CO 



CO 



CO 
CO 

3 



CO 



(A 



(0 

(0 
3 



m 

3 
O 
10 



o 

Li. 

m 
o 

o 

>- 
o 
z 

u. 



03 
3 
O 



c 



CO 



UiO 

UiZ 
flCO 

a 



(0 

o 

i 
J 
2 



xi 

coO 

o 



o 

CO 

ca 
c 



o 



z 

Q< 

toc2 
ztu^ 
r)>cc 
zo 

o 



§ 
8 



CO 



o 



Z 
UJ 

OS 



CO tr 



» c 



S 
o 

CO 
(0 



LU 

a 
O 

{£ 
CL 



OD^ 



S5 

CO m 
CO O. 

II 



as 
c 

if 

<a'co 
« o 



CO 



CD 
T3 



m 
o- 

CO 



o>o 

0. 



o- 

CO 



a o « 

go 



J 



J9f 




S © i3 O O 

— <D 



. 9 

1X3 
ui< 
2> 

ZlU 



0) Q> 




C 

I 



q: ^ 



as? 



CO 

CD 



CO 
CO 

"0 

2*- 

CO 

o 



CO 



c2 
« w 

0.(0 
CD O 

^ to 
"c 



03 5g 



SUBSTmiTE SHEET (RUU 26) 



wo 96/34350 PCT/OS96«)5678 




CD 



llKGCO 

GLOa< 



SUBSTHUTE SHEET (RUL£ 26) 



WO96O43S0 



PCT/US9««5«78 



5/9 



§ 



to 



z 

oa: 

HO 



CM 
O 



UJ 

cn 
3 



Po 



>e » 



=0 



8 



Ui 

ii 
=^1 



E 

(0 

c 

S 3 



CO 

o. 

0) 
(0 

to 

9 tn 

iS 9^ 



1| 
8-1 



CO 

o> 
' c 
o a 

50 









z 








0 
m 


LU 




2 


OS 


V 


0 


JNIT 
SUR 




N 




ME 


UJ 






2 



















usesi 
^currer 


belonj 




i OPAI P 



c ? 



I? 



EUJ 
Sot 

iru 



(0 

o 

X 

a 
< 

o 



o 
tn 




SUBSmUTE SHEET (RULE 26) 



wo 96/34350 PCT/OS9(M>5678 



6/9 



CLASS? 



600 



■610 



614 



BUILD. EOIT 
OR DELETE? 



BUILD CLASS 



-616 



EDIT CLASS 



-612 



618 



DELETE CLASS 



CLASS 
PROPTY? 



620 



624 



BUILD 
CL PROPTTY 



BUILD. EDIT 
OR DELETE? 



-626 



EDITCL. 
PROPTY 



-622 



628 

A. 



DELETE 
CL PROPTY 



REUSHIP? 



634 . 



BUILD. EDIT 
OR DELETE? 



BUILD REL'SH. 



636 



EDIT REL-SH. 



-630 



632 



. 638 



DELETE 
REL'SH. 



640 



FIG. 6 



StlBSTITUTE SHEET (ROU 26) 



WO9d/34350 



P(n7US96W5«78 



7/9 




700 



TRIGGER TRANSL. 



SELECT CLASS 



CREATE TABLE 



CREATE COLUMNS 



CREATE COL FOR PROPTY 



CREATE COL FOR REL'SH 



770 



FIG. 7 



800 ObjID 

/ NAME MFR 



ObjiD 



•710 
720 
-730 
740 
-750 
-760 



NAME CITY 



820{ 



SIZE 



COUNTRY 



FIG. 8 

SUBSTITM SHEET (RUU 26) 



wo 96/34350 



PCTA)S96/05678 



8/9 




SPECIFY 
CASCADE 
SEARCH 



911 



OBTAIN 
LIST OF 
CLASSES 



912 



-913 



-914 



, SELECT 
CUSS 



SELECT 
RELATED 
CLASSES 



OBTAIN 
LIST OF 
PROPTY 



S 915 




916 



PAF 
CASC 
SEA 


ISE 

:ade 

RCH 






BUILD 
SQL 
QUERY 



-920 



921 




940 



931 



RE-UNK 
CONFIG. 
OBJECT 



^922 




BUILD 




FURTHER 




CONRG. 




OBJECTS 




^932 




TABLE 




ALIAS 




ANAL. 



-933 



-934 



JOIN 
ANAL 



SEARCH 
COND. 
ANAL. 



935 




TRANSMIT 
SQL TO 
ENGINE 



950 



APPLY 

SQL 
QUERY 



•960 



PRESENT 
RESULTS 



FIG. 9A 



SUBSTITUTE SHEET ^RUli 26) 



wo 96/34350 PCT/US96/0S678 

9/9 




r 



S4 



[re) 
[pi] 



-991 CONFIGURATION 
OBJECT 



SI 



S2 



S3 



R1 



R3 I 



-992 QUERY MODEL 
OBJECT 



-993 ALIAS OBJECT 



994 JOIN OBJECT 



-995 CONDITION OBJECT 



F/G. 9B 



SUBSrnun SHEET (RULE 26) 



INTERNATIONAL SEARCS REPORT 



vmtffooil AppUcafioo No 

PCT/US 96/05678 



A. CLASSinCATlON OF SUBJECT MATTER 

IPC 6 6e6F17/3e 






Acooitf iif to International Pattar Oas«6cafioB (IPQ or to botti Bslioiial dnaficatiflo aatf IPC 




B. FIELDS SEARCHED 


MininuBD 

IPC 6 


documcntaiion KVdMd (danficahon syscm followed by d«f 


iettea qinboH) 




Doewacautioo searched odicr tfun mtminum dooBBcaatiOD to ihc cxictt dwt web dociBDM ai« incluM ift tfw fiddi wiiTtwrt 


Bcctpome < 


data faaae ffoondtrd durin$ Sw intcnialional aeaicb (same of data 


but nd, vtaai pncliai, loRh «nBf «Md] 




C DOCUMENTS CONSIDERED TO BE RELEVANT 




Otaitoo of docuoaod, wiOi indicaaoa whn appropiute, of the rdcvim paaafo 


Relevant to dans NtK 




H0.A.95 12172 (WALL DATA INC :KROENKE 
DAVID M (US); OLDS CHRISTOPHER C (US): 
KAWA) 4 Nay 1995 
see abstract; claims 1-36 


1.5.8. 
10,12.16 


A 


Vrt).A,95 G3586 (PERSISTENCE SOFTWARE INC) 2 
February 1995 

see page 3, line 7 - page 4. line 6 


1»5.8. 
10.12.16 


A 


US,A,5 291 583 (BAPAT SUBODH) 1 Harch 1994 
cited in the application 
see abstract 

see column 2, line 45 - column 3, line 62 


1.5,8. 
10.12.16 


A 


US.A.5 295 256 (BAPAT SUBODH) 15 Harch 
1994 

cited in the application 

see column 2, line 52 - column 4, line 18 


1.5.8. 
10.12.16 






-/-- 




[x] 


» donaMM in luUd n flt* coMauaboa of bar C 


1 Patent faimly menibcn are lined in aAncx. 


' Spcoal cattgonca ol died docimntt : 

'A' docurneM deflniai Sm general Aaie of Ihc ait wtech ii M 
coQfldmd to be of |>tr«cular reUvaiKc 

'E* earlier docmml but puUidwd on or after the mtamaboml 
filing date 

'L* doctraenx wfeich may throw doute on pnonty dainift) or 
which a aicd to csiabiith ttic puUicaaon date €>f another 
atahon or other i^coal rtasoo (at qpceificd) 

*0' documcni refcmng to an oral dttdoeure, use, nhibtoon or 
other means 

'P' doomwnt publiAed pn or to the inirmatiacial filinf dale but 
later Qian the pnonty dale claifncd 


nr later document piJbtidied afUr (he BitrmaftoiMl filin| date 
or prwrity dale and not m eoaflici with the appbcaooB bol 
Qtcd to undcnttad the pnnapic or theory underlying 8m 
mveadoo 

'X* dociBBcnt of pannilar rdcvanoe; die daimed invcnboo 
canneft be consdercd nowd or cannot be ooraadcrcd lo 
involve an invrnovc it^ when the document u taken alone 

'Y' documcni of pafbodar idcvanoe; ttae daimed lavcnbon 
cannot be consdercd to involve an snvcnDv* sup whco the 
documcni n combined with one or more other audi docu* 
menu, euch eombiiiaBon being obvious to a pcnon sftoUcd 
tn thean. 

*A' document member of the aame patent faimly 


Date of the actual coreplciioo of the imonaoonal search 

9 August 1996 


Dau of mading of the mtetnational search report 

09. a96 


Name and majhng addrcts of the ISA 

European PatEflt Office. P.B. 311 « Paieodaan 3 
NX -3310 HV Rtpwijk 
Td. ( * 31-70) 340-3040. Tx. 31 631 tpo nl. 
Fax 31-70) 340-3016 


Authonzed officer 

Katerbau, R 



Fofm PCT.1SA.ai0 (MOBAi ihwi) tJidy f m) 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 

PCT/US 96/85678 


C(C(XKIBU>&CD) DOCUMENTS CONSIDERED TO BE REliVANT 


Canfeqr* 


QttlloB «f Jonwnrwi. wift McMioQ, who* approfiitMt of Ok rdtvant pasafct 


RdcvtnttocUimNo. 


A 


EP»A,0 504 685 (IBM) 16 Septenter 1992 
cited in the application 
see abstract 


1,5.8. 
18.12. 16 



page 2 of 2 



INTERNATIONAL SEARCH REPORT 



lemalioni] ApplicaliaD No 

PCT/US 96/05678 



Patens document 
cited in teirch report 


Publicaliea 


Patent family 
nsenibcr(s) 


Pu^fictiioa 1 
dale 1 


WO-A-9512172 


04-65-95 


AU-B- 
CA-A- 
NO-A- 


7955294 
961698 


22-65*95 

04-05-95 1 

V"T V«# 9^ 1 

26-06-96 


WO-A-9563586 


02-62-95 


US-A- 


5499371 


12-63-96 


US-A-529I583 


61-63-94 


NONE 






US-A-S295256 


15-63-94 


NONE 






EP-A-e50408S 


16-69-92 


US-A- 


5212787 


18-05-93 



Fetn KTnSA;3ia (PMMi family 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

kf^LACK BORDERS 




□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 
^BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

\^ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




